Test Driven Development
I have just returned from Antalya in Turkey for the Most Valued Professional conference for MEA (Middle East and Africa). You folks were great, especially when the power went off and I had to restart my VPC.
I used VSTS to show how to do Test Driven Development (TDD). The reaction amongst some of the attendees was the same as mine initially. It just seems a bit mad. The process is pretty simple:
- Create a test
- run it, watch it fail
- do the minimum in code to make the test pass
- refine the test by making using more data or adding to the test algorithm and go to 2
The endpoint is reached when all the test code is complete, and all the tests either pass.
In normal development of course the creative initiative is from the developer, who codes up a function and then declares that it is ready for testing. In TDD the initiative comes from the tester and the coder must adhere to step 3 and do the bare minimum to pass the test.
So why not just complete the function in step 3 and wait for the tester to catch up? Well because we want to end up with a fully tested state that contains no redundant or intronic code. I draw an analogy here to how DNA works in coding life. DNA contains codes that do absolutely nothing to define the species. In fact there are not replicated by messanger RNA. These sequences are called introns. Well when you code a function you may introduce reduncancies like introns into your code. For example creating a variable and manipulating it but not using it to calculate the final result, things that a perfect optimizer would be able to find, if we could write such an optimizer. These introns in your function can slow it down or hide potential bugs that we may not find.
So write the minimum necessary to pass the test and do not jump ahead and do the whole function. A hard discipline for a programming professional.
When folks challenge me on this approach, I answer with the following:
- Do you think that all code should be tested? Yes!
- So at the end of a project you will have a body of code, a full set of tests and a comprehensive set of test data? Yes!
- In traditional development how often is that end point reached? Not always!
- In TDD (if done rigourously) how often would that end point be reached? Always!
- QED
The main problem with implementing TDD is from developers themselves. They now take a backseat to the creative initiative of the test engineer. (Of course they may be the same person but for large projects they will be different). To an experienced developer this stinks! I suggest that you think of taking your best programming talent and having them either architect the system down to the class and function level or have them write the automatic test code (in C# or VB.Net).
We need to rethink the role of developer and tester in software engineering.
