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 defined
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.

Developers who have already been working on collaborative, agile teams will be more open to this change in approach, and may even have some experience with unit testing or even BDD. It’s easier for small teams starting new projects to jump into TDD instead of introducing it in the middle of a project. If all else fails, call in the Agile coaches: There’s plenty of them who are well versed on the topic and eager to assist.

2. Developers need testing skills. Developers may lack the skills needed to write good tests and may have zero motivation or time to learn. In that case, the developer should work closely with a tester or business analyst, who will define the test script. Once that’s done, the developer can write the code to run the automated test. In some cases, an organization will have testers who have experience writing automated tests. Regardless, developers and testers will need to learn to work together much more closely than in the past.

3. Testers must adapt to automation. Automated testing is becoming pervasive in organizations. Testers who fail to accept that fact will often struggle to provide value, but those who embrace it should be able to succeed. The availability of test automation will change manual testers’ roles, as basic validations can (and often should) be automated. Manual testing is typically reserved for testing that validates the system’s performance against business needs and customer expectations. Additionally, testers who contribute to automation and appreciate its benefits can provide value in a wider set of circumstances, and will find their voice is heard more often at the table.

4. Mitigating possible business risks. TDD has been criticized for removing the final safety net of manual testing. Yet the purpose of TDD is to develop a product that is already fully tested and vetted, allowing code to be pushed to production with less risk. Increased quality risk is largely a perception versus reality, although some applications might be too complex for the TDD approach. If you’re just getting started with TDD, it is ideal to prove the model out first and run a pilot project for an application that is not tied to customers or revenues.