TDD to Prove Code Innocent

Source: https://medium.com/with-love/tdd-and-having-fun-coding-34364d4df0a0

What is TDD?

Test Driven Development (TDD) is a software engineering methodology where we make unit tests first before implementing the feature to make sure all of the user requirements are fulfilled. TDD is an iterative flow that consist of 3 steps in each iteration.

“All Code is Guilty Until Proven Innocent”
That line mean that our code that implement a feature are still guilty if we can’t prove it innocent. Proving code innocent mean that we have test the code implementation with some scenario called test case in the form of unit test and our code is proven innocent only if it pass the all the test.
The section below will describe in more detail how to apply TDD.

TDD Flow and How to Implement it

Source: https://womanonrails.com/tdd-basic

RED

In the first phase named RED phase, we write unit test for our code that implement the feature. We make the test first to ensure the quality of the code implementation will be good because we have imagine the use-case scenario and know most of the corner case before writing the code. Obviously, the test on pipeline in this phase will fails because we doesn’t implement the feature that will be tested yet.

RED Phase: Make Test for Error Handling Feature

Example: We test something that we don’t implement yet

GREEN

In the second phase (GREEN), we implement the feature that answer the unit tests we create earlier. We focus on writing code that can pass the unit test (which is fit the user needs and handle corner case). We can run the unit test very easily and get the result of the testing scenario. After that, we make further implementation based on the report on testing until we have pass all the unit test.

GREEN Phase: Implement Error Handling Feature After Writing the Test

Example: We make implementation code for test that is failed

REFACTOR

Refactoring phase aim at code adjustment on the feature that we have created by change the code that we make for better code quality. We just improve the code quality without changing what that feature will be doing. In this phase, the test result that have been success (Green) earlier should not be fail (Red).

REFACTORING: Refactor Existing Code for Better Code Quality

Example: Making changes that the purpose is only to improve code quality

Why use TDD?

The reason we use TDD is because it offers some benefits to you and your team. Here are some of those benefits:

1. We have a clear indicator that our implementation code must achieved because we make some test based on the user requirements before writing the implementation code. This will help the entire team project to understand what they should do in implementing a feature.
2. We can achieve a better quality assurance on our code because all of the code we implement have gone through 3 phase. On the first phase, we define all of the requirements and the corner case; On the second phase, we make implementation code based on the requirements and handle the corner case; And on the last phase, we change the code in order to improve the code quality.
3. With TDD, we can reduce the bugs that our code will introduce. It is because if there is a bug in our code, it will not passed the unit test and we can easily know it just by looking on the test status/report.

Now we know what is TDD and how to implement it. We also have seen some benefits on applying TDD in team project and my team has experience those benefits too. In my opinion, TDD is more like a good habit that hard to start with but is very good if you can get used to it.