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.
- Part 1: Getting started with unit tests
- Part 2: Working with network requests in TDD
- Part 3: Working with the DOM in TDD
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.