Understanding Test Driven Development

One of my friends had told me that they were implementing Agile practices and Test Driven Development in their organization. When asked “What is Test Driven Development”, he answered “the testcases are developed first and the software is written to the testcases”. He also explained that it helps catch the errors sooner than later. This is true. But he couldn’t explain anything more than the DNA of the Test Driven Development as to what were the other benefits that you can reap of the Test Driven Development (TDD) if you implement it in a right way.

 

Well, let’s not do something just for the sake of it.


It is perfectly true that the TDD model helps you catch the errors sooner than later. But more than that, TDD offers the implementation of “microscopic” approach in the project implementation through Incremental and Iterative cycles.

First, what is it all about testcases?

• Test Cases are direct means of communication among the developers, users and other stakeholders to understand the system in correct and in comprehension and arrive at a common and formal page of contract.
• It is the language where the stakeholders talk to one another at a lower level of implementation.
• Test Cases are nothing but “executable specifications” of the system that you are developing. A good set of testcases is nothing but “working code in plain English”. Did we get it right before jumping on to TDD?

Theoratically, there are different models practised for the implementation of TDD.

-----------------------------------------------------------------------------------------

• In a pure and religious Agile model, the developer owns the responsibilities of test case development and the execution, along with the developing the code to those testcases.
• In other models, there is still a dedicated Testing team and the Testing team develops the testcases in parallel with the code constuction.

-----------------------------------------------------------------------------------------

Irrespective of the model your team is following, you need to ensure you are developing the comprehensive (Test for Good & Test for Bad; Functional & Non-Functional) set of testcases before jumpstarting to coding your iteration or sprint or feature - whatever the TDD in picture is for. Otherwise, TDD comes of no additional value in your project.

 

To illustrate with an example from my experience, we used to implement TDD as follows:

 -----------------------------------------------------------------------------------------

• Depending on the team composition, team skills or the interest of the individuals (which you need to respect), the team members used to play varying roles.
• Development-Only
• Testing-Only
• Both Development and Testing
• There were no hard and fast rules on the above team composition but the team would do it through "collaborative planning". Yes, "team collaboration" should be applied in planning phases as well, as a side note.
• Developers used to wear those Testing Hats in the development of the critical pieces of the software. This could be from business requirements point of view or technical implementation point of view.
• The Test Engineer or the TDD-Developer will come with his first set of estcases and call for a "review" meeting with other team members.
• And believe me - these review meetings are the places where a lot of brainstroming used to be done and people get into a lot of interesting discussions and raise a lot of questions and get answers. This also proved to be a very effective informal platform for the Knowledge Transition.
• Interestingly the "take away" items from these TDD meetings used to be:
• Expected Results answered (DONE)
• Expected Results unanswered (TODO item for the Developer, TODO for the Test Engineer, or a QUESTION to the customer)
• New Testcases developed
• New Testcases to be developed
• Overall an "executable specifications" coming into a shape on a "collaborative platform".
• Everyone understanding of the system a little more and a little better.
• ...
• The developer would now start with the code and possibly with those TODO comments which will need to be answered shortly.

-----------------------------------------------------------------------------------------

Refer to my article "TDD is a Control System" to understand a few more practical facts of paying continuous attention to improve the Quality of TDD beyond an iteration cycle.

If you a Project Manager:

• What is that you are doing to ensure your team is practising the right TDD principles than mere "Test First, Test Early" approach?
• How are you ensuring the collaboration of the individuals that the "Wisdom of the group" is used for building up the "Executable Specifications" or formally "Testcases"?

If you are a Developer or Test Engineer:

• Did you ensure you've got the testcases "correct and complete" before constructing the code to that list? Rememeber TDD is all about minimizing the rework and refactoring.
• Are you ensuring you are communicating to the Test Engineer beyond formal meetings?
• Did you get those unanswered questions in your TODO list and in your TODO comments in the code before they end up as a BUG reported by someone else at a later stage?

  

"Right Practice is what you need to ensure Quality, name of the Process makes no difference" 

(Attribution: Images on this post are downloaded from FreeDigitalPhotos.Net)