Test Driven Development - Step by Step

My first step toward TDD

Vinay was convinced by the TDD approach, but he wasn't sure where to start. Unfortunately, he didn't have the chance to use an xUnit family tool because of time and training needs. But Vinay was keen to start following TDD myself, so he discussed the concept with the team and set some rules:

1. Write the unit test cases related to any functionality in the document first, prior to writing the code.
2. Always use track changes in the document (this helps ensure that test cases are written first and tested later).
3. Mark the status of the test case "fail," since no code will yet have been written to implement that functionality.
4. Write enough code to implement the functionality.
5. Test the unit test cases written for that functionality, and update the status.

It was tough to get the entire team to follow these rules. And, as I'd expected, Vinay received strong resistance from everyone. One question raised by the team was how to write a test case without implementing the functionality. Even he had same questions about this initially, but they proved unfounded. Even the testing team writes test cases only on the basis of requirement documents. Eventually all of us agreed to follow this method, and to review it after couple of releases to find out if it was truly helpful and sensible.

After a couple of releases, these were my findings:

1. Developers get a better understanding of functionality and are able to visualize the behavior more appropriately. Since they must write test cases prior to development, they are able to think about functionality in a way that meets the end userís expectations.
2. Developers are able to think about more possible test scenarios, both positive and negative, and implement them accordingly in the code.
3. Developers gain more confidence over their implementation because they have tested it well.
4. After one or two releases, the whole team is able to understand the gaps and fill them in over the next releases. (For example, in one case the missing element turned out to be lack of business knowledge at the team level.)

Now the only pain left was in regression testing and retesting of old material because of any new changes. And this was not possible with manual processes; it called for more time. However, the process as a whole helped us stabilize our releases to a certain extent.

Courtesy

This article was originally published in Scrum Alliance blog; Published here with the permission from author.