How do you help people embrace TDD? (Especially if they don’t want to do it)

People often ask us how we get software engineers, product owners, whole businesses to embrace Test-Driven Development (TDD). During a session at this year’s Software Design for Medical Devices (SDMD)  global conference, industry leaders in medtech asked us: how do you help people embrace TDD?

So, I’m going to try and answer that question.

My name is Jane, I’m a Software Engineer here at Bluefruit Software. It’s at this point that I must confess that I was in that position once. I was one of those developers who didn’t want to do TDD.

Coming from a more traditional coding background, I once believed that developers write code, testers write tests, and you (the dev) shouldn’t test the code that you wrote.

Testing was for testers, because it was considered a flaw for developers to test their own code. Why? If the developer knows how they have implemented their code, they can just write a test that passes in that scenario. So, it still might not work as it was meant to.

Besides, wouldn’t it take longer to complete my work? Wouldn’t it slow me down and stop all my creative ideas by forcing me to pause and gather thoughts?

The answer is that for most medium to large size (or complex) applications; it saves time in the long run, as complexity increases and interactions between different units become increasingly intertwined.

Saving time bug hunting

In maintenance costs, and bug hunting when something stops working that used to work months ago, TDD can save a lot of time. Anyone who has been in this position without unit tests to help you out will realise it can be frustrating to figure out what broke that thing that used to work. It can take a long time.

If you had a series of automated unit tests, you would know when making code changes that another test elsewhere had started failing and been able to fix code changes in a timely manner.

We have had that experience at Bluefruit. We uncovered a showstopper defect in one of our client’s products—after a few weeks of investigation—it was found to be an error in some driver software. An area that isn’t typically unit-tested. Had this been anywhere else, it would have been located in a fraction of the time.

Why TDD is worth your time

Here are some of the things that helped to convince me that TDD is worth it:

Start easy

My first foray into TDD was a part of my recruitment assessments for Bluefruit Software. Bluefruit values TDD very highly due to the gains you get in code quality.

Everyone applying as a developer takes part in a coding test to show TDD and coding skills while you complete logic problems using a tool called cyber-dojo. It’s an ideal training environment where you can write tests and then add the code to make them pass. When the tests pass, you know that your code is doing what you intended it to, and that is reassuring.

If you don’t have time to do this sort of training, pairing with someone experienced at TDD will also help make the benefits clear before too long.

Doesn’t it slow me down?

You would think that having to take some time to write a test up-front would mean everything takes longer. However, the majority of studies have shown that TDD  improves productivity due to how it decreases defects in code, including this one from teams at Microsoft and IBM (link opens PDF).

The study showed that starting to write code itself takes a bit longer compared to just getting stuck in. But in this case, thinking more about the intention of the functionality upfront means that you have a better understanding of the project earlier, and this better understanding tends to lead to projects with higher-quality code. As the study discovered:

“The increase in development time ranges from 15% to 35%. From an efficacy perspective this increase in development time is offset by the by the reduced maintenance costs due to the improvement in quality.”

TDD makes a real impact on quality.

Does it really improve quality?

Yes. Studies have compared test-first development approaches such as TDD against test-last development when unit tests are written after the code.

That Microsoft and IBM study found that the occurrence of defects in projects using TDD decreased by between 40% and 90% compared to projects where TDD was not used.

Other studies have involved intentionally injecting faults into the code to see how many of them were caught by tests. A study conducted by Brunel University London and several other institutes (link opens PDF) showed test-first detected a mean of 83.5% of errors, compared to 57.5% for test-last.

But should developers test their own code?

Unit tests written as part of test-first do not replace other types of testing, such as integration testing, user acceptance testing and exploratory break testing. These will test the functionality at a higher level. As the test is written before the code, a developer is not really testing their own code but instead coding to pass the pre-written test.

Including more automated unit tests also reduces the load of manual testing required, making testing phases quicker for releases:

Click on image for larger view.

Other benefits

In my current role as a Product Owner, my focus has changed. I like the confidence in the quality of software that a nice automated test suite of unit tests gives me. These results can form part of a quality report to stakeholders.

From a regulatory, compliance perspective, the test results form part of the evidence of code quality.

Writing tests also encourages a developer to think about the intent of the functionality to be developed and prompts all the questions and clarifications up-front, so when they do start developing, they know more about the goals. As a Product Owner, I make myself available to answer these questions as and when they arise.

Nowadays, I’m a big TDD convert! And I hope some of these answers will help to convince your more reluctant developers, too.

Written by Jane Orme.