Software testing is changing for the better with the rise of agile and DevOps. Instead of testing occurring at the end of the development cycle, modern methods integrate testing into every step of the process. By moving testing earlier, using Test-Driven Development (TDD), features can be released immediately after passing automated tests.
TDD is becoming integral in enabling Continuous Delivery or Deployment (CD), a popular agile concept. CD reimagines the traditional software development and deployment process, replacing the drawn out and coordinated phased approach with more frequent and accelerated activities around individual features. Beyond allowing features to release to customers more frequently, TDD can also increase developer productivity by avoiding developer scope creep, through the red-green-refactor cycle. The benefits of TDD can be tremendous, but it’s important to take thought and consideration into its adoption so that process, tools and people involved transition smoothly.
TDD is a novel approach to testing that flips testing from the end of the cycle to the beginning. To do so, it almost always requires defining and building an automated test before the developer writes any code. Once the test completes, the developer then writes a feature and continues to revise until it passes the test, providing instant feedback on the quality of the software being developed.
TDD (and the complementary practice of Behavior-Driven Development) provides additional flexibility down the road to re-architect or refactor the software as it becomes inefficient. The automated tests needed to ensure that software continues to perform as expected have already been written and are ready to be rerun against the new code. On top of that, TDD separates features from each other so you can refactor and improve pieces of the application separately as you go.
(Related: The huge role of automation in testing)
For legacy apps, TDD might be harder to introduce, due to the overwhelming number of automation tests that may need to be written to cover pieces of the software, which have already been implemented. But for new software being developed from scratch by agile teams, TDD is an ideal approach.
Overcoming a few TDD challenges
1. Developer pushback. Logically, writing tests and performing them while code is being written makes a lot of sense. Developers can fix issues on the features they are currently writing, instead of waiting until after they’ve moved on to a different project and have changed gears mentally. Code is ready to go faster, and with in-progress assurances that it will work as expected for users.
On the other hand, developers don’t often like to get mixed up in the process of testing. They are creative spirits, and may also resent being reined in to write the code exactly to pass the test. While some developers may hate the rigidity TDD enforces, others may be glad to avoid rewrites later.