Let’s find Answers to Common Objections about TDD

7 min readAug 5, 2019

TDD has been quite a known and essential practice in Agile Software Development which is originated from Extreme Programming. However, there are some misconceptions involved in spite of the benefits of TDD. TL;DR: The main intent of this blog is to answer a few of the objections or few of the misconceptions commonly raised about TDD and help build the courage to follow TDD practice.

Author: Bharati Koot, Software Craftsperson at Nelkinda Software Craft Pvt Ltd

First Published: 2019–07–23 by and at Nelkinda Software Craft Private Limited

1 Introduction

This blog talks about TDD practice in Software Development which is becoming popular since quite a few years.
However, still, the essence of TDD is ignored under the common misconceptions and objections about the same.
So, the primary focus of this blog is to introduce TDD very shortly for newbies and put more light on the objections and relevant answers to them. Those are derived with own experience and mainly inspired by the Robert C. Martin (Uncle Bob) Clean Code video series.

2 What is TDD?

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only.

TDD Definition from the [Wikipedia:TDD]

The TDD technique has been developed by Kent Beck however TDD has been closely related to Extreme Programming practice Test-First Programming. TDD gives courage and enforces us to write clean code.

3 Let’s Quickly Walk Through The 3 Laws of TDD

Write no production code except to pass a failing test.
Write only enough of a test to demonstrate a failure. Not compiling is failing.
Write only enough production code to pass the test.

The 3 Laws of TDD by Uncle Bob

So, as the 3 laws are quite self-explanatory by definition, however, the important part is to follow them rigorously without violating the essence of those.

The following picture illustrates TDD in one go.

4 Why TDD?

Because: it

increases Primary Value of Software
gives you faster feedback about your code
gives you the courage to change or refactor your code
saves your debug time or rework time
keeps your code cleaner and simpler
allows you to write flexible and easily extensible code
makes you tend to use SOLID principles naturally
helps you to design and structure your code
seizes the need for separate specification documents, as your tests are the specification

These are few of the most stated benefits of TDD and you will find many to this list at other forums.

But, still, the misconceptions around TDD exist and the following section lists a few of them with answers to them to encourage people and organizations to follow the practice.

5 Objections About TDD and Obvious Answers

TDD is too hard

Well, in the beginning, you might feel so, and which is absolutely okay.
We need to practice and practice it like any other skill or habit until it comes as a natural way of working with ease.

Does TDD slow you down?

Actually No. It makes you fast in the long run as you save time on debugging which incurs in the absence of a good suite of tests.

I am a very good programmer, and I don’t need tests to validate my code

If you are a very good programmer, congratulations! The normal human tendency is to think and act “I do always best”, which is okay. However, we work in teams. If someone else breaks the code, what is the fasted way to spot the bug immediately? Of course, the tests!
With tests, you get faster feedback. So, having tests in place is quite useful for yourself and for the team itself.
And, the bonus is TDD will actually make you the best programmer!

Can’t make the boss agree on following the TDD practice

First, do it, and show them, and make their misconceptions go away.
If still, they do not agree, do it anyway as TDD is a personal practice like any other personal practices or habits.

But, TDD takes a longer time than normal programming

Most of the times, the concept understanding, practicing to not violate rules of TDD, and getting familiar with testing tools and environment takes time.
And, mastering anything needs time, but until you learn to master it. Otherwise, TDD keeps your code cleaner and simpler and which saves time at any point in time.

Who will test the tests if you follow TDD?

It is obvious that your tests will test the production code.
So, the reverse is also true.
Your production code will test your tests.

Refactoring is additional work

As we all know, anything can’t be just perfect in the first place. It has to go through rework and iterations.
So, refactoring is not additional work, it is as good as making your code craft better and cleaner.
Be reminded that there should not be any such phase as refactoring but it should be standard practice during implementation.

Maintaining tests will be too costly

Treat your tests as important as your production code, then you will not have to worry about its maintenance.
Design your tests well and refactor them frequently along with the production code.

Can we write completely bug-free code if we use TDD?

The goal of TDD is not to achieve completely bug-free code, of course, if we can do so, it is most desirable.
But the key thing behind following TDD is that we get the courage to change the production code whenever we need to without fear.
The goal os to eliminate the fear of change.

But, then why test first?

Because they increase the primary value of software that it is soft to tolerate the ongoing changes to the software.
Yes, tests are important! And, they are perhaps more important than your production code.

How to use TDD for legacy code?

The Legacy code seems risky to touch as most of the times they do not keep tests to verify your changes to that legacy code.
You can start with a small part of the legacy code that you can test without making big design changes and then use those tests to extend design changes more safely.

How do we test a GUI?

You can split the GUI as Presenter and View, and the presenter can be tested. So you can test the low layer of GUI that controls the GUI.

How to test Databases?

Databases are like black boxes which we don’t need to test. But, we can test if generated query behaves properly.
Separate your Application from the Database and test it without Database with few aspects related to Database tested.

Developers think testing is not their job

Understand the basic thing. The test is also a code. Most of the testing frameworks are written by Developers.
Those who think testing is not their job need to grow up and know that testing and development are not a separate thing, they go hand in hand.

What QAs / testers will do then?

Ideally, QAs / testers should work closely with the development team.
While developers focus on unit-level testing, QAs and testers focus more on integration level testing and find the blind spots and scenarios that are missed by developers. As a developer, we may not consider all the real use case scenarios, but QA will definitely spot gaps around those.
There are several blogs around this which you can read as further reading to understand the role of the QA / testers in a TDD environment.
Further Reading: Testers in TDD Teams

TDD is good ONLY for simple or small projects

That is not really true. If you design the test architecture of your system quite well, you can use TDD in any kind of projects.
You need to know the test pyramid and implement tests accordingly in your projects. You can use ATDD, BDD along with TDD to test your code at different layers of the test pyramid.

TDD will increase my project budget

Well not really. Invest a penny in the right thing and have a glass of 🍺 beer in the evening! Sounds not so good?
You will probably need to invest in upskilling your team for TDD practice. But that investment gets paid already with the increased primary value of software, faster response to production defects, saving future maintenance cost, and keeping already a happy Customer.

6 What’s Behind and What’s Ahead

When I look at those misconceptions around TDD, I find one major thing behind that, and it is FEAR!
Fear of starting to use it. Fear of failing if you start to use it. Fear of delays. Fear of unknown. Fear of CHANGE.

Hold on! Give away your FEAR! Look ahead where it will bring you.
As, with TDD, the primary value of software increases, it says it all about why you should use it.
For being more Agile, being faster in responding to changing needs of Customers, being ready and on time for “time to market”, being flexible enough to add or remove features, writing high-quality code, and crafting your code well, always start using TDD.

So, Happy TDD!!!!

Author: Bharati Koot #BBK

Originally published at http://nelkinda.com.