Member Article

What Is Test-Driven Development?

Test-driven development, or TDD is a popular software development practice that has gained much traction in recent years, particularly in teams aiming for alignment with Agile or DevOps methodologies. £References to TDD stretch back to the 1960s, but its modern rediscovery has been attributed to a man named Kent Beck, an American software engineer and the creator of extreme programming.

Empirical research published in the Empirical Software Engineering journal found that teams using TDD had a pre-release defect density (defects per thousand lines of code) 40-90 percent lower than teams that didn’t use TDD.

But just what is TDD? And what use can your development teams get from implementing TDD in software dev projects? Does TDD call for a new set of test metrics to get actionable insights that improve software tests? Find out below.

TDD Defined

Test-driven development is a methodology in which you create a set of software tests first before coding the application-it is shift left testing in the extreme. The tests initially fail, with the whole point being to consider the requirements of a feature or a section of code and writing code that allows the test to pass.

Why use TDD?

There are generally two broadly accepted opinions that, without drilling down into details, tell you why teams adopt Test-driven development.

• Reason 1: TDD provides a solid basis and technique for specifying your software requirements and design before writing the actual program code.
• Reason 2: TDD leads to higher quality software because developers focus on what is necessary to pass the tests, eliminating redundant or superfluous code.

TDD Benefits

The specific benefits of TDD for development teams are significant, and they include:

• Finding bugs faster because you get immediate feedback on whether the code is working—if the initial code you write doesn’t pass the pre-written tests, you know about the bugs now rather than later. It is cheaper to fix bugs the earlier they are found. As IBM reported, the cost to fix an error found after product release is then four to five times higher than those uncovered during product design.
• By writing code that changes a test result from fail to pass, you know you now have working code and a functioning regression test.
• TDD is a way to verify that the code being called in test cases fulfils the product specifications.
• TDD enables code refactoring, which means tweaking existing code so that it is better designed. Since the code has full test coverage (tests already exist to verify functions), developers can refactor code and re-run automated tests to verify the code still works and the tests still pass. Without TDD, refactoring is risky because developers never know if the changes they make will break a functionality.

TDD Issues and Challenges

With all the benefits of TDD, taking on such a change to your team and processes comes with its own set of challenges.

Time

It takes significant time to initially write tests that effectively verify a requirement—writing such cases requires creativity and excellent coding. The time-consuming nature of TDD is such that you can expect a 10-20 percent increase in initial development time, which is a big problem in a market that expects faster, more frequent releases.

However, as you’ve seen, writing testable code early on tends to lead to fewer defects later on, when defects cost more money and take time to fix. Any increase in development time is arguably offset later on when software using TDD tends to shine through with fewer defects and less time spent fixing things such as regressions.

New Philosophy

In many cases, TDD represents a paradigm-shift for programmers who are used to coding in certain ways. Some developers might not like the change, because TDD requires significant alterations in normal coding practices.

Furthermore, there is a mental and psychological strain when taking part in a TDD transition – it might feel as if a project requires mountains of work at the beginning. However, overcoming this hurdle simply means reminding yourself that the development speed will pick up after the initial difficulties.

TDD and Test Metrics

Test metrics still fit into a TDD environment—after all, you still need a way to measure if your software tests are effective. This means test metrics can provide insight regardless of whether the software has been designed around test cases. In fact, TDD and test metrics can complement each other in leading to better software tests.

Some examples of test metrics you can use to get feedback on testing processes (including TDD) are:

• Code coverage—while TDD implies high unit test code coverage, it’s still useful to track code coverage because low coverage in a TDD environment means something has definitely gone wrong with implementing Test-driven development. Never set certain code coverage targets, as they are too easy to game. The idea is to monitor the metric and see if it’s lower than what you’d expect in an environment where code has been designed to pass test cases.
• Defect density—ideally, there should be fewer defects in a TDD environment than when you didn’t use TDD. This metric tracks the number of defects per thousand lines of code, and it provides a useful gauge on how effective your TDD implementation is.
• Cyclomatic complexity—this test metric measures the number of linearly independent paths through a subroutine’s source code, and several tools can calculate the value for you. The implication is that the more complex a program (or subroutine) is, the more likely it is to end up breaking. Implementing TDD, you should expect a decrease in cyclomatic complexity compared to not using TDD.

Closing Thoughts

• Test-driven development provides many benefits, including less time fixing software defects as development progresses, higher quality software, catching errors earlier, and ensuring the code developed meets the product’s specifications.
• The challenges associated with implementing TDD include a high initial time investment and a paradigm shift that can cause confusion and annoyance among developers who need to change their approach to coding.
• However, the initial difficulties with TDD end up paying off in the long term with less time spent fixing defects and lower defect density.
• Despite the difficulties, test metrics can provide valuable insights into software testing for teams using TDD. Metrics can also provide feedback on the efficacy of a TDD implementation.

This was posted in Bdaily's Members' News section by Mary .