Test Driven Development
What is TDD??
Test Driven Development. A Development that Driven by a Test.
TDD is an approach or a development technique that requires unit tests to be written first before they code they are supposed to validate, or you implemented. But how are we make a feature by testing first? It seems like we doing things backward, but this approach is also useful to do a project. Here is some insight TDD in our Project Moodah.
What is Test Driven Development?
The TDD adopts a “Test-First” approach in which unit tests are written before code, the only reason for which will be the successful execution of these tests. It starts with designing and developing tests for every small functionality of an application. Then implement features just enough to pass said tests.
The process finished then we start again at the beginning as it become a cycle. Slowly the test become a specific with each failed test case, at the same time the software is improved so that the tests pass just passes and do refactoring if needed until the feature has finished developed.
TDD’s Flowing Cycle
Test-driven development (TDD) is an iterative process where the unit tests are developed just before the implementation. It’s a tight feedback loop consisting of these steps:
- Write a unit test, watch it fail.
- Write just enough code to pass the test.
- Improve the code (without changing its behavior).
These steps are often referred to as “red, green, refactor,” for the way in which the tests go from failing (red) to passing (green), with a final opportunity to improve the code and the tests (refactor). Then we repeat it over and over again as it become a cycle.
1. [RED] Failing Test
These tests are created in hopes to meet the expectancy of the software functionality. These tests are then committed as [RED] or failing, because we have nothing that can pass these tests yet.
2. [GREEN] Passing Test
Next step we try to produce code sufficient enough to pass this unit test. It means that it allows the “worst” solutions. The aim is the code fulfill the criteria of the test, the functionality that can fulfilled the test for the developed feature.
3. REFACTOR without Changing the Behavior
In previous step, we basically accept any code as long as it enough to pass the test. It means that there’s probability there will be some dirty codes in our codes, improving our codes. This is also a chance where we can check the code itself, not only cleaning the dirty code, but also the structure itself.
The Benefit and Why we use TDD in Moodah
When working in Team you usually, divide you works into several task in your team, but remember that when you working on a feature, it will later be integrated as one.There are several benefit in using Test-Driven Development, here are several reasons on why we implemented this practice:
Avoids Code that Cannot be Tested
Using TDD approach means that you avoid scenario: You write a whole bunch of code, then you try to figure out how to test it. Remember that when creating code’s means it can affect the behavior of previous code that we make.
Working in team means that you need to make sure that your code not only just working properly but also good enough by acceptance to be integrated to the rest of the code. Which means it passed the acceptance test. If we make the test first, we can make sure all the functionality in a test is there before we integrated it. But if we make the test later, there’s a chance that we missed test that could’ve been there.
Make sure the Code that we write Clean
One of the TDD phase that is refactoring will help us get the code clean. Clean code is essential for working for the team in developing a software. It not only help yourself, but also your team. For further information why clean code is important you may read another article about this:
Safety Net in Development
TDD give safety net for developer to carry out the refactoring and continuous improvement work essential to the success of the method. It also give us a chance to develop things to be more maintainable and reusable code that facilitates the addition of new functionalities, because we knew that we have more.
Providing test first before we refactor thing will help us with other benefit. It allows problems to be detected as early as possible, which has the effect of reducing the cost of resolution but also the number of bugs, especially if we doing continuous integration. It is also good because with this we can keep the scale tight for the feature.
Higher Coverage
Test coverage is defined as a metric in Software Testing that measures the amount of testing performed by a set of test. The code coverage provided by the unit test series is intended to be maximum with a minimum of well over 80%. Because we have to passed the tested first before we recycle, it will be logical that we have more test coverage.
Example
Here is an example of what I did. Not in Moodah but for other project. For this project I use Django as the framework.
There are 2 tests that I made. The first one is a test for checking the status response from a certain directory or Route. The way we test it is by fetching the Route and check the status code. Status codes are issued by a server in response to a client’s request made to the server. If the status response that we get is not 200, then the test will be failed.
The second test is to check if the certain route use a specific file or not, if correct then the test will passed if not then the test id failed. In my case the second file is to check whether the route /Peony/ rendering the ‘Profile.html’ or not.
After making the test I try to run the test and the result is..
FAILED because at this moment I only make the test, and the app don’t have any router yet. The next is I make the route and the template for profile, because both of it is the requirement for the test. I make it as minimum as possible and the run the test again.
This time the test is PASSED.
The next thing to do is REFACTOR, without changing it’s behavior and if it is necessary. As long as you are sure that the code is already clean, we can add new test to be test, and continue the cycle. You can also see if the test passed or not through gitlab. For example if you push the RED test it will failed because the pipeline won’t work.
In here the RED TEST is failed and it will give a red x mark. If the test success it will give a green tick mark.
Make sure that when you refactor the end result is also in a tick mark.
Conclusion
Test Driven Development is a one of the practice or approach in developing a software. It gave us benefits when we are implementing a feature in the software that we develop and give us a safety net while we are working as a group to make sure that the software we develop is maintainable and clean.
That’s all thank you!!!
