Many companies follow a rather traditonal model of software development and quality assurance, where the features of the software are implemented based on business requirements and then tested once the implementation has been completed.
Even in an agile development cycle, errors are often found late and the test coverage of the projects are low. Test Driven Development (TDD) is a practice that tries to address these issues.
The TDD Cycle
The approach is simple: write a test that fails, pass it in as simple a way as possible and then refactor the code. This cycle is known as the Red-Green-Refactor cycle.
When practicing TDD, before implementing any actual program code, the developer formalizes the desired behavior of a given feature by writing an automated test for it. The test is nothing more than a piece of code that makes it clear what a particular piece of the software should do.
When run, the test fails because the actual functionality has not yet been implemented. The developer then works to get this test to pass by implementing the required functionality with as little code as possible.
The Red-Green-Refactor cycle is repeated as many times as necessary, until the feature has been completed.
By creating the test case before implementing the unit, problems such as misunderstanding of requirements or interfaces are reduced and at the end of the development cycle all implemented functionality is guaranteed to have test coverage.
To write the initial tests, the developer must understand in detail the specification of the system and the business rules. In addition, the tests should follow the FIRST model:
- F (Fast) - Tests must be fast, because they will be run all the time.
- I (Isolated) - Tests may not depend on each other, so they can be run in any order.
- R (Repeatable) - When a test is run multiple times, it must have the same results.
- S (Self-verifying) - The test must check by itself if it has passed with no human interaction.
- T (Timely) - Tests must be written about the same time as the code that is being tested (When practicing TDD, the tests must be written first!)
Advantages of Test Driven Development
The software is being tested constantly through the development process and is guaranteed to have a very high test coverage. Developers gain an understanding of the business rules early in the development cycle, because it’s a requirement to be able to write the test cases.
The ready-made tests will validate if any modifications did not create problems in the business rules that were already in operation (Regression).
What makes the difference between practicing TDD and writing tests later?
The main reason for increased software quality is not the TDD practice by itself, but the automated tests, produced through it. The common question is then: What is the difference between doing TDD and writing the test later?
The developer gets feedback from the test. The difference is precisely in the amount of feedback. When the developer writes the tests only after the implementation of the production code, a lot of time already passed without the developer getting any feedback on it. The earlier the developer receives feedback, the better. When one has too much code already written, changes can be cumbersome and costly. Conversely, the less written code, the lower the cost of change. And that's exactly what happens with TDD practitioners: they get feedback at a time when change is still cheap.
The other difference is that when following TDD a high test coverage is guaranteed, whereas a traditional approach might leave you with only a few tests when time runs short.
Conclusion
TDD is an interesting method to skyrocket your projects test coverage and increase code quality. It integrates well into agile development processes aiming to anticipate problems early and making the project less susceptible to failure.
It comes at a cost, since most developers don’t have experience with it and thus if you plan to enroll it in your workplace it will require some training and willingness of everybody involved to try something different.
