In traditional development models, a programmer’s primary focus and first task is to write code. Testing is a follow-up step to validate that the code behaves as expected and is often done manually by running the application. In most cases, the primary testing is performed by another team (typically the Quality Assurance [QA] team), while the developer may only do basic validation themselves. The Test Driven Development (TDD) approach flips this process on its head.
In this model, the programmer’s first task is to write the test that will verify the acceptance criteria or success of the proposed functionality before any code is written. There are several advantages to this approach:
- The developer is forced to focus very closely on exactly what will make this code successful: the acceptance criteria or expected results.
- All output and expected results are validated programmatically – reducing human error and mistakes.
- These tests are automated and repeatable so any changes to code that impact the functionality will be detected and be addressed.
- Code is more thoroughly and consistently tested prior to delivery to QA, enabling the testers to spend more time on higher value testing.
- Refactoring – the process of re-writing/improving code over time is less error prone since the automated tests validate that no changes to the functionality have been introduced in the process.
As we discussed in a previous blog post, the concept of quick feedback cycles is key to the agile software development process. TDD is another example of a quick feedback cycle. By providing the developer with almost immediate testing results and validation that their code meets the output requirements or acceptance criteria, we shorten those cycles and ensure that errors are caught as early in the process as possible. By incorporating these automated tests into our Continuous Integration Pipeline, we ensure that, not only does any new code meet the test requirements, but all previous tests also pass – preventing any unexpected impact to existing functionality.
At Datafaction, we have recently implemented the TDD approach for all of our teams. This required us to prepare the teams by training them in automated testing techniques as well as setting up the required infrastructure to enable the automated execution of these tests as part of our process. We now require tests to be written for all modified code. Our Technical Team Leads validate this as part of our code review process. We also make use of an automated tool called SeaLights* that detects any code that has changed but does not have an automated test that executes it. Highlighted as “Quality Risks”, these modified and untested code areas are a good way for us to focus our testing efforts and ensure that we have properly implemented TDD.
We hope that the TDD approach will help our team focus on the quality of the software from minute one and will lay the foundation for maintaining that quality throughout the process.
*SeaLights is not affiliated with Datafaction, City National Bank or RBC
Previous posts from the author: