Test Driven Development: Developers Magic Wand

Published in

Swift India

5 min readJun 10, 2018

Let us go through a story.

“Not in distant past, I had provided a build of my application to the tester which was about to go live. I had made some fixes to it which as per my dev sanity testing had made build production ready. But after the testing, the situation was completely different. I got bugs in some cases which were due to my earlier fixes. What the Hell??? Instead of making my build stable, I made it more unstable.”

I wasn’t the only one who confronted this situation, but many developers confront this too. So what can we do to prevent this? The answer is Test Driven Development(TDD).

What are we gonna learn?

There are many blogs on TDD. I will list down some of the best references that you could find out there. We are not gonna discuss theoretical TDD concepts, rather we will focus on how we could plan on implementing TDD from a developers perspective.

What is TDD?
Why TDD?
How to plan out TDD?
Caveats of TDD.
Do you need TDD?

Does it seem too many? Don’t worry we will make this fast and short. ;)

What is TDD?

Test Driven Development is a development procedure proposed by American software engineer Kent Beck in which we write down our test cases simultaneously as we write down our code. Thereby allowing us to test our code concurrently as we keep on developing. The following image describes the difference between traditional development and TDD.

In traditional development, we develop our code first, complete the functionality and go for manual testing. But in TDD, we write down our test cases first and then develop our code accordingly. This helps us in minimizing the chances of code failure or bugs. Any new functionality developed should respect the existing test cases as well, if old test cases are not to be updated.

TDD is based on the concept of RGR i.e Red, Green and Refactor.

Red: We write the failing test case first.

Green: We write the minimal code required to pass the test.

Refactor: We refactor our code if required our test code as well.

Why TDD?

Minimises the chance of code failure.
Minimises the chance of errors by any new developer in the team working on the code base.
Less chance of breaking existing functionalities due to the introduction of new features or bug fixes.
Improves product knowledge.
Improves coding standards.

How to plan out TDD?

Here comes the million dollars question? We all know what is TDD.

But how are we gonna plan out TDD? How are we gonna decide what are the test cases that we need to write? Am I gonna write and develop the functionality, and then write tests for them or how is it gonna be? Confused?

Understand the functionality to be implemented properly.

Let us take an example of the following requirement:

Requirements:

Build a program which will take population input of a city from the user and will return back with the category to which the city belongs.
Following are the type of the city with their population ranges:

Small (5,000 to 10,000)
Medium (10,000 to 50,000)
Large (More than 50,000)

Break down the functionality to sub-functions. Consider this as the breaking of each functionality in terms of methods in the programming sense.

We break down the whole implementation to following sub-functions:

Take input regarding population from the user.
Prepare a method which categorizes the population count and returns the type of city by customizing your output.

Preview the UML diagram for the functionality. Consider the classes that you will build, the properties and methods that you will be using to achieve the requirement.

We can have the following set of classes with a rough estimation of our classes and associated properties and methods.

determineCityType() -> Holds the logic for determining the city type based on the population.

configureOutput() -> Holds the logic for configuring the display to user.

Write down test case for each of the functionality. Each sub-functions can be broken down into functions.

Now we should write down test cases predicting the above class diagram. Its a good practice to write tests for each classes and their functionalities. Referring the above UML diagram, we would like to test attributes of City and CityCategorizer and also test the determineCityType() and configureOutput() methods.

Caveats of TDD:

Slows down the development process.
When initial test cases are written, the complexities of future enhancements are not predicted.
If requirements change frequently, you will end up in wasting much of your time reconfiguring your test cases.

Do you need TDD?

If your project is short-term based and is not gonna be there for a long time, you might want to avoid TDD.
If your project is not scalable, you should avoid TDD.
TDD works great if your project is scalable and has a huge code base.