Test Driven Development

Test driven development, abbreviated as TDD, is a software development paradigm with the repetition of different cycles. It is a programming practice where the test drives the development process. The programmer first writes the failing test case of small functionality, makes the failing test case to pass and then refactor the code in order to make it clean. This process is called red, green and refactor process.

Uncle Bob defines TDD with three rules:

  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Why TDD?

Many tech companies were surviving and making good revenues before TDD. There were different other paradigms followed to make different softwares. They were happy and ok with it. So, why do we need TDD?

TDD has several benefits. Some of them are:

1) Fewer bugs hence low debugging time.

2) Clean and tidy code.

3) Good tests make good documentation.

4) Less maintenance time and cost.

Three phases of TDD:

No alt text provided for this image

1) Red: Before TDD, what we used to do was create a class and methods and write some codes and then write unit tests. But in TDD, we start from the test case. We write the failing test case. Because of the failing test, this stage is called red.

For example, we are implementing an addition functionality in our calculator application. First, we create a test case for the addition class.

No alt text provided for this image

There is no Addition class and an add method, which is why the compiler is showing an error (marked with red color). In the code above, to run the test case, first, we have to create the Addition class with add method inside it. In this case, the test drove us to real development. Let’s do it. The IDE generated Addition class looks like:

No alt text provided for this image

Now let’s run the test case. We expected that the addition of 2 and 3 will produce 5 as a result. Let’s run it. We can see the test failing because the actual result is 0 but we are expecting it to be 5.

No alt text provided for this image

This is the demonstration of red phase of TDD.

2) Green: It’s obvious that the test case would fail in the above case because we haven’t provided the real implementation. In the green phase, we will change the implementation and write the production code. Also, make the failing test case pass. Let’s do it.

No alt text provided for this image

That’s the easiest code I have ever written after Hello World. Let’s run the test case and make it pass.

No alt text provided for this image

3) Refactor: Finally, the test passed, after a great struggle (Just kidding!). Now, in this stage, we will refactor our code. Remember, in our add method, the name of the parameters were i and i1. Does it make any sense? After renaming the parameter, the method looks like:

No alt text provided for this image

This stage involves mitigating redundancy, implementing clean code and following different principles. It’s easy to refactor in our case because the add method doesn’t cover each and every corner cases. You write the test cases for every corner cases, make it green, refactor it and hence the development will revolve around this cycle.

This is a simple overview of TDD. TDD becomes more handier when you practice a lot. This project can be found in github.

Thank you for reading my article. [linkedin article]

Connect with me in linkedin.