What Is Test-Driven Development?

Test-Driven Development (TDD) is a time-tested approach to creating software solutions that emphasizes testing software as it is being written, not as an after-the-fact effort as often seen in traditional development. This approach was created by Kent Beck in the late 1990s as part of the Extreme Programming framework and was written about in the book, "Test-Driven Development By Example."

This iterative, test-based development approach takes an upfront investment of time, but the process has been shown to:

• Drastically reduce defects
• Improve design quality of the code
• Increase overall technical quality

That upfront investment is often paid back in decreased debugging effort and reuse of automated tests to quickly confirm the correct behavior of a system as it evolves.

Other means of tests driving the development of a system include Acceptance Test-Driven Development (ATDD) and Behavior-Driven Development (BDD). How TDD differs is that unit tests have a finer-grained focus and are typically written in the same programming language as the system, while ATDD and BDD focus on collaborating with the business people and documenting that collaboration as tests written in a more customer-friendly language.

Defining Test-Driven Development 

Scrum Alliance defines TDD as an approach to writing code that keeps development goals short and well-defined and the end product modular and flexible. Since agile is all about shorter, more iterative and flexible ways of working, TDD is a practice that is incorporated by many software development agile teams.

When practicing TDD, three activities are tightly interwoven: coding, unit testing, and design (via refactoring). The process works in the following ways:

• Create a test that expresses how the system should behave.
• Run that test, which should fail because the program lacks that feature.
• Write “just enough” code, the simplest possible, to make the test pass.
• Refactor the code until it conforms to the simplicity criteria, often the Definition of Done.
• Repeat, until the product backlog item meets its acceptance criteria.

Here’s a short example of TDD using javascript from Learnitmyway.com that illustrates this process.

You can read the discussions that helped originally define Test-Driven Development at Ward Cunningham’s C2 wiki.

Benefits of Test-Driven Development

Scrum teams that use TDD are able to be more agile since the technique demands an iterative and incremental approach that complements scrum. Rather than writing large batches of code and testing them at the end, TDD is done at the user story level which is always the smallest possible increment of work that adds customer value.

With a test-first focus, scrum teams build stronger collaboration and leave less room for misunderstanding. Developers within the team work together on what it means for a product backlog item to be correctly implemented and considered done. This happens before any code is created and is confirmed as the code is written. This practice is typically done with both a software developer and quality assurance engineer working together rather than handing off code from one to another.

The practice is also shown to boost customer and stakeholder confidence in the product by knowing that the scrum team has a strong commitment to delivering a high-quality product.

Teams practicing TDD often write just-enough code and tend to not over-engineer. Tests are a client of the system which results in less speculation on what code may be needed by other clients. This focus leads to less code to implement, test, and maintain.

One extra benefit of TDD is with each product backlog item the team builds up a test automation suite that can be run to give quick feedback on the state of the system. Tests can be run as part of your continuous integration build and by developers on their local machine as they make changes. When all the tests pass your team is confident the system is behaving as intended.

Potential Downsides of Test-Driven Development

As with any new practice there’s an initial learning curve with TDD. The team and its stakeholders need to understand that they’re going to have to initially slow down in order to speed up over time.

A lot of team members have worked a certain way for many years and may find this new way of working uncomfortable, slower, and frustrating, especially when there are schedule pressures to deliver. If your developers and quality team are used to working in silos, you may have a few hurdles to overcome in order to get them collaborating together and not ‘owning’ a particular part of the process. 

Some teams have also experienced partial adoption, where a few team members are comfortable with TDD, but the rest of the team still uses traditional development and testing methods. 

A downside of the suite of automated tests is that it is a body of code that needs to be properly maintained as the system evolves and new features are implemented. Neglecting to maintain the test suite can result in tests reporting failures when they are not updated to account for the changes in the system. As the test suite grows it could also take more and more time to run all tests, which causes developers to not run them as frequently, missing that quick feedback cycle.

Test-driven development allows your team to iteratively write tests as code is developed, leading to higher quality software and reduction in future testing time needed because you’re building a test automation suite. This practice enhances a scrum team’s agility since the practice is iterative and incremental, making it easier to handle changing requirements. TDD also builds team collaboration, which is what scrum is all about.

--

Get Certified as a Scrum Developer

Stand out in a competitive job market as a Certified Scrum Developer. Your certification from Scrum Alliance showcases your verified skills in the scrum framework and specialized agile engineering.

Scrum Developer Track