Looking Into the Basics of Test Driven Development
Introduction
Test Driven Development (TDD), a combination of Test First Development (TFD) and Refactoring, sits in the Agile camp and is a methodology where the development team writes tests before they even start to write code. They then run the test and if it fails they write the code to ensure the test passes. On passing the test, the code is then tidied up or refactored and a new test is undertaken.
It sounds simple, and to all intents and purposes it is, but it does call on a strategic change in mindset from all those involved—and this includes management. This change in mindset is one of the major obstacles in undertaking this approach to software development as there needs to be a lot of investment up front and work can seem to progress slowly.
The Basics of TDD
The diagram takes us through the simple iterative flow of building and running a test, building some code and then refactoring. It is a completely different way for the development teams to work, writing a test that is sure to fail as no code has been written. In this section I will take each step and explore in more detail what is entailed and how this relates to previous techniques.
Step One - Test
First of all, for each new feature or module a new test needs to be written. This test will inevitably fail due to it being written before the module exists. For the test to be written, the developers must understand what the requirements are for the feature set by extracting them out of the User Story. The main difference with TDD compared to writing traditional unit tests is that it encourages the developer to focus on the requirements before writing the code.
Step Two - Code
The next step is to write some code that will allow the test to pass. This new code will not necessarily be perfect but will be sufficient to pass the initial test. The next step will take care of tidying up the code and ensuring it meets quality expectations.
It is most important to understand that the code written at this point is only designed to pass the specified test; no extra functionality should be included.
Step Three - Refactor
In this stage, the code written to pass the specified test is improved to meet quality expectations, remove duplications and ensure it complies with departmental or corporate standards—this is called refactoring. As the tests can be rerun at any time, confidence in the code can be maintained by performing the specified test again to ensure that it still passes all the criteria.
Why Use TDD?
A good reason for embarking down the TDD route is that it enables you to take a more modular approach when building software. For example, it is by far easier to find an error in a few lines of code compared to trawling through dozens, if not thousands, of coded lines. The implication is that the faster your test suite, the more attractive it is to proceed in smaller and smaller modules of code.
Coming from an Object Oriented background, I applaud any process or technique that promotes code reuse or modularization. As a development team gets more familiar with TDD, they will then be in a better position to take advantage of object libraries and regression techniques, again improving both quality and delivery expectations.
Kent Beck, in his book Test-Driven Development by Examples stated in 2003, “TDD encourages simple designs and inspires confidence.“1 By breaking work down into individual components that can be specified through pre-written tests, we are able to build solutions that can easily be regression tested and managed through the development process. These solutions will then be built by simple modules with clearly defined interfaces, which interact with each of the other components in a simple mapped out design.
Summing Up
Test driven development is a technique where you first write a test that fails before you embark on writing the code. TDD must not be seen as a replacement for traditional testing, but it should be seen as a way to outline a proven way to ensure good unit testing. As each TDD test is effectively a working example for each coded module, it can therefore be described as a source for providing working specifications for that module also. Embracing the TDD route is not easy at first, especially so for those who are from a traditional development background, but with perseverance the benefits will soon manifest themselves in quality deliverables.
References
- TDD image: Michael Kirkham-Jones
- 1 Beck, K. Test-Driven Development by Example, Addison Wesley, 2003
