Test Driven Development

I just had an interview with an applicant from our company and one of the questions that we had to him is if he has done Test Driven Development. For most part, I would say, most of the applicants that I have interviewed does not have a clear grasp of test driven development. They thought or most of them thought that just because you have a unit test, means it is a Test Driven Development. One of them was even describing Integration Testing rather than Unit Testing. So I thought of publishing a short and concise understanding of what really is Test Driven Development..

What is test driven development ?

Test driven development is a software development process of which for most part, the test has more importance or if not has the same importance with the code. That is, test are first created even before the actual coding/logical coding is done. It is difficult to understand this concept but in essence, it is a development style of which codes undergo exhaustive testing.

These are the concepts of TDD according to my notes based on a TDD book I've read way back.:

1. You maintain an exhaustive suite of Programmer Tests. - You have a programmer's test that tests your classes exhibit the proper behaviour.
2. No code goes into production unless it has associated tests, - All codes must have an associated test before it goes to the next environment for integration testing. This means that if there's a change of code, there must be a test for it or you don't propagate the change. Similarly, this is applied to new functions.
3. You write the tests first - You write the test first. Write a test that will fail initially, and then test. Pass at the minimum of 2nd time then refactor or keep on testing until it passes then refactor.
4. The tests determine what code you need to write. - This helps limit your code to the actual functionality that needs to be implemented and nothing more.
5. Let the computer tell you your errors.

The following are the simple rules of applying TDD as per my notes based on a TDD book I've read way back :

1. Think about what you want to do.
2. Think about how to test it.
3. Write a small test.
4. Think about the desired API.
5. Write just enough code to fail the test.
6.  Run and watch the test fail. (The test-runner, if you're using something like JUnit, shows the "Red Bar"). Now you know that your test is going to be executed.
7. Write just enough code to pass the test (and pass all your previous tests). Run and watch all of the tests pass. (The test-runner, if you're using JUnit, etc., shows the "Green Bar"). If it doesn't pass, you did something wrong, fix it now since it's got to be something you just wrote.
8. If you have any duplicate logic, or inexpressive code, refactor to remove duplication and increase expressiveness -- this includes reducing coupling and increasing cohesion. Run the tests again, you should still have the Green Bar. If you get the Red Bar, then you made a mistake in your refactoring.
9. Fix it now and re-run. Repeat the steps above until you can't find any more tests that drive writing new code.

Now the general concept and reason of TDD is actually to : Force programmers to think before they act.