TDD — This World is Full of Test

This article is written as an Individual Review Assignment for PPL CSUI 2021

TDD — known as Test Driven Development is one of Software Development approach. For some, TDD is something that was feared and only increase someone workload. But for some, TDD is something that was pretty much useful and can be our life saver during code development.

Some people is going to ask, “when there is Quality Assurance team going to test your code, why should you do it by yourself?”. The answer is, because if we wait for the QA team to test and found the problem, we have already made ton of features and looking for bug in mountain of code is something hard. If you can find those bug as soon as you can by yourself, why should wait from the others?

The Life Cycle of TDD

In TDD Cycle, there is three step within a cycle. For easier explanation, I am going to show some of my work implementing TDD during the Software Design course project. The example of this TDD is implemented by using Python with Django framework

1. RED

During the RED stage, here we make a tests that was meant to be failed when you run the tests. Prior to adding a lines of code, it is better for us to list what that code supposed to do, and what do you expect from that code. You can do it one by one per function for better implementation.

Figure 1.1.1 — A commit that show RED stage in TDD Cycle

Figure 1.1.2 — Adding a new lines of test to be implemented in the features later

Do mind that by listing your features and what should they do one by one, then you have to implement the features one by one as well. One job meant one TDD Cycle. From the test that was made in RED stage, you can start to write the code to match the given test case.

2. GREEN

The GREEN stage, where you started to implement your code to pass the test that you have made. Each time you made a test with RED stage, it should be followed by GREEN for good implementation. If you have implemented the code based on the test and it still failed the test, it is mean that you do not make test or correctly. Possibly you make a features with dependencies to the other first.

Figure 1.2.1 — A commit that show GREEN, passing test that was made before

Figure 1.2.1 — Implementing the Serializer

Figure 1.2.2 — Implementing the features to passes the test made

Figure 1.2.3 — Adding URL so the features can be used

3. REFACTOR

The REFACTOR stage, is where you make a change to code but does not change the implementation. REFACTOR should be done when you found some Code Smell or anything else to prevent bugs.

Figure 1.3.1— A commit that show a REFACTOR to change models to return data in sorted way

Figure 1.3.2 — Changes made in Models to sort the returned data

One thing that you need to remember when doing REFACTOR is to not change the result from your code that affect the test that was made before. REFACTOR purpose is to fix something that was unexpected, if you wanted to change the logic of some code, make a new test that is going to fail and implement the code to passes the test again.

Important Things to Note in TDD Cycle

1. Check your Code Coverage

Figure 2.1.1 — Coverage Report after running test

When you implement a test in RED — GREEN — REFACTOR fashion, do you think that you have made a bug free code already? The answer is, it is not certain. You have to make sure to check you Code Coverage when you ran a test. If you do not have a 100% Code Coverage, that means your test still misses some part of code you have made. This missed line of code could lead to some bug that you will not expect.

Even if you have a Code with 100% Code Coverage, does not meant that your code is bug free. There is still possibility that you have not tested unexpected behavior yet. Given that 100% Code Coverage can still lead to bugs, what if it even less than 100%? Definitely more chance to produce more bug, yeah.

2. Make a Positive and Negative Case for test

Figure 2.2.1 — Example of Positive Negative test case

Implementing TDD Cycle meant to lessen the bug produced in your code. In order to make sure that your code was more bug free, you have to implement a test case with positive and negative result. By implementing test with positive and negative result, you can mitigate the problem that could possibly happening due to outside of your expectation even if you already having 100% Code Coverage.

In My Opinion

Advantage of TDD

When you were developing a product that was going to be used for a long time, which mean constant updates. The TDD cycle can surely helping so much since, every time you change some implementation, the tests is going to be fail. By knowing which test is failing, you should know that there was potential error or the code itself need to be updated. Further more, developing in TDD meant you have to implement a functionality one by one in small step, which will lead to Small Function in Clean Code.

By having TDD Cycle implemented, you can handle such basic test case or even advanced one based on your test. This way, you can lessen the probability of bug from your code. When you found out that certain case have not been handled yet, you can handle it by yourself. You do not have to wait from others to test it and then reporting you mountain of problem that you need to fix at once. On my other project, I have once saved by the Test that was already made when I changed the code without changing the test first. It really saved me from trouble to find the bug without testing for sure.

Disadvantage of TDD

TDD comes with set of advantage, but does not mean it have no disadvantage at all. First of all, implementing TDD comes with more code. Since you have to code a test first, and then implementing it. When you have to code more, that mean you have to spend more time for a feature as well. Learning how to do TDD is not easy task as well, since in some programming language, you have to learn how to mock data.

Conclusion

TDD is something important, that was my opinion. For me, the most important part is the Test itself, which is more important than having implementing in TDD cycle. But developing with TDD cycle will help you to know what is the product should do. Which mean, TDD is not bad thing to implement even though it was consuming a lot of time.

End of the lines, thank you for reading this article. I hope that this article will be useful for anyone who read this. So if you were developing a project, would you like to do it in TDD cycle or just a test or just code without test?