PPL 2020 — Software Methodology: TDD

Steven Kusuman
3 min readFeb 24, 2020

Disclaimer: This post is written as a part of a university course, and its main purpose is to give an overview, in no way this is to be viewed as a complete guide to TDD.

One of the problems in the world of computing is figuring out the correct way of producing Large-scale, bug-free software. The use of formal methods based on mathematical models to prove the correctness of a software shows great promise and appears to be the ultimate technique for producing reliable software. However, the practical accomplishments in this area fall short of a tool for routine use. Fundamental problems in reducing the theory to practice are not likely to be solved in the immediate future. Another alternative is the use of test cases to detect bugs.

This article tried to explain the basics of Test Driven Development (TDD), it is one of the practices used in software development to reduce the number of bugs in a software.

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 code is improved so that the tests pass. This is opposed to software development that allows code to be added that is not proven to meet requirements.
- wikipedia

That’s basically TDD for you. TDD as explained above helps you in a number of things. When we convert requirements into test cases, it helps us to understand the requirements better, we also get to think about how to implement our program and write down edge cases that will introduce bugs in our program. With the test ready, we can do code refactoring without having to worry if it introduces new bugs or not, simply run the test cases again after each refactoring.

The following sequence explains how TDD is implemented:

  1. Add a test
    We start by designing our test cases based on the requirements, and then push the tests to a remote repository, without first implementing the code. This stage is called the RED stage, and we expect the tests to fail.
  2. Write the code
    Create an implementation enough to pass all the current test cases (do not add further code that doesn’t have a test yet or adding any test cases in this stage). We then push this code to a remote repository. This stage is called the GREEN stage, and we expect the code to pass all the test cases.
  3. Refactor
    If we wanted to improve the readability of our code, we can do code refactoring and then run all test cases again. Please make sure the code passes all the tests before pushing it to a remote repository. This stage is called the REFACTOR stage.

TDD Limitations and Cons

I’ve explained the benefits of TDD above. Unfortunately, TDD also has many limitations.

Tests become part of the maintenance overhead of a project, and for some people it can become quite cumbersome, TDD means writing and maintaining an excessive number of tests, which costs time and can often lead to fragile code (especially in frontend, where code changes often). You should also be aware of testing anti-patterns, which you can read more here.

Now, to give you a sense of how to incorporate TDD in your development flow, I’ll show you an example of how we use TDD in one of our team projects. Hopefully, you can learn a thing or two.

How do we use TDD in our development flow?

The example below is given as part of our university course. In our course,
we must strictly use TDD in our development flow, our test cases are also required to be high-coverage, and reach at least 90% of the code. Here is an example of testing a repository code.

This test is first pushed with the [RED] tag, we then continue to implement the GetById function in our repository, if all the test cases are cleared, we push this code to a remote repository, together with a [GREEN] tag. If any code refactoring is needed, we first start with the code refactoring and then run the test all over again, if all test cases are cleared, we push this code to a remote repository with a [REFACTOR] tag.

--

--