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.