/* Code Musings */

Test Driven Development Philosophy

I might be splitting hairs with this post, but that’s what a blog is for. I run into this topic fairly frequently.

Test Driven Development (TDD) is that act of writing tests prior to writing the guts of your function or class. The point is that you write your code first, then writing the code to be tested. It sounds backwards and in some respects, it is. I love explaining the subject to new developers, such as students or co-ops, and watching their reactions. In some cases, it provokes a knee-jerk reaction from seasoned developers, which is frustrating to say the least. They cling on to their ideals as if it was the alpha and omega of programming.

But, I digress…

With TDD, you would first write your function or method declaration. The implementation of which would only contain enough code to make the compiler accept the code as valid syntax. For methods that don’t return anything, just leave the method empty. For others, return the default value type. You would then start writing many unit tests to exercise your code. This is easy to grasp.

So, in a discussion like this, I asked a colleague why TDD is done or what is the purpose behind testing first. The answer is fairly easy – write tests to test a black box with information only about its signature. Simple. And on a scholarly level, this is the end of the discussion. However, I like to continue the conversation on a philosophical level, and ask ‘why’?

Some developers don’t know how to answer that and give me a runaround answer. As with my discussion with a coworker today, that is exactly what happened. I was told that’s how it is and not to question it. Alright, but I refuse to work without understanding why I do things a certain way. Again, ‘why’?

If tests were to be written afterwards, the programmer would test her implementation rather than the black box or interface. She would, either knowingly or subconsciously, avoid testing certain cases due to known limitation of her logic. And I am guilty of this. Luckily, I have caught myself and adjusted my ways. You can obtain similar results by having another person write the unit tests, one that does not have knowledge of the implementation, only the interface. Many disagree with me on this on the basis of their strict conformance and unquestionable faith to TDD. I state that the point of TDD is to write tests void of any information of the implementation, which does not necessitate it being written prior to the implementation. It is just easier for one developer to achieve.

Leave a Reply