Test Driven Development
What is test driven development and why do it
As I sat down to write some code today, I decided to read about test driven development.
Uncle Bob (Robert Martin) has written his three rules of TDD which are:
- that you can’t write code other than to make failing tests pass,
- that you can’t write unit tests any more than what is required to fail, and
- that you can’t write code more than what is required to make the failing test pass.
This was wonderful principle. Following it makes you write unit tests every minute. And that is good as the article explains.
I followed it up with a three part series on test driven development in javascript by James Sinclair
- Part 1: Getting started with unit tests
- Part 2: Working with network requests in TDD
- Part 3: Working with the DOM in TDD
This is the point where my interest in functional javascript got piqued.
I also started to wonder if there are alternatives to test driven development, whether TDD is the way to go.
I read this article on how TDD isn’t just testing.
The learn-tdd github project is a quick overview of all the tools we need (this is where I came across code coverage tools).
I also read this discussion about how not to do unit tests? (Make sure you read the comments)
And a post about why TDD is bad. This and the PDF linked at the end of it would make less sense if functional programming is used, I think.