Testing perversion

This is quite a harsh title for the article but I think it describes the current tendency for where the TDD is heading. Yes of course there is no denying that testing is essential for any software and the more coverage you have the assured you are of the robustness of your product, but do you really?

TDD and Agile has become quite a trend in nowadays, many developers visit seminars and follow key agile people to hear how testing is important and how it will make life easier and in a certain way I agree with this hypothesis... BUT (you knew there will be a but here) do those developers really understand what TDD is all about?

The rules of TDD are quite simple: "you are not allowed to write a single line of code unless you see a failing test" and this is a perfect guidance in a way, but what does it actually mean? In my practice I have seen a lot of code - bad and good, and what I am gradually getting at is that our test are also simply code, it is a code that ensures that our production code works correctly. So it is like a babysitter that we hire for our child that will ensure that he or she will be safe - but who is watching after the babyitter?

Around 60% of the test that I have seen were badly written. You know what I am talking about because I believe I am not the only one to hear: "Yes we totally coverered that module with test, but do not touch any code in there you never know what might happen" - WTF? The whole purpose of writting tests is that you are not afraid to change your code, they ensure that the behaviour that you expect will be adhered to without any compromise. So why are people so afraid? and the answer is simple - we write the test just because we can without any though put into what we are trying to achieve. Developers spent tremendous ammount of time covering their code with tests that are useless and in fact in future they become more of a burden rather than help, because test require maintenance; and bad test require 10 times the maintenance. At some point you just find yourself choking in all the failing test that you keep trying to fix instead of developing software product like you really should

My thesis is simple: a good code needs a good developer, a good test needs an excellent developer.

It is not enough to read agile/TDD books, articles and attend conferences you need to understand what you are doing and take full responsibility for your action. The outcome of your work should be code that no one will be afraid to change because change is the only constant is the software development world.

So before you write a line of test next time ask yourself:

1. what am I testing?

a clear purpose should be defined before any line of code for test is written

2. am I testing more than one thing at a time?

each test should be testing just one function/functional purpose of software, because to much information inevitably will infer a bias on your testing results

3. how usefull my test will be if the functionality is to change?

change is the only constant - this is the primary question how to make your code less frightening to evolution of your software

4. am I using the correct tools?

there many good tool available nowadays and it is very important to use the correct tool to suit the purpose of yout testing. do not try to use all the tools that are out there just because you know their names - keep it light.

5. do I know how to use my tools?

before using any tool a good study of the functionality it provides must be made. as 80/20 rule states people are using only 20% of the functionality of the software 80% of the time - do not allow this cliche to be on you. I have seen so many times people using 2 or 3 tools for testing just because they did not know that the first one already had all the features necessary but the developers were just to reluctant to learn.

I hope that my article has enlightened some of you, the bottom line message is do not follow a trend, be a professional and by all means please do not interpret this like anti-TDD article but be sure you are applying your knowledge correctly, rather than waste your time on writting useless tests.

This page was last updated on: 14/06/2009 16:44