Test-Driven Development: Safety First!
If you are familiar with the software development cycle, you might as well familiar with the term “Test-Driven Development”. To those of you who are new in the field, well, welcome aboard! I’ll explain what you need to know about Test-Driven Development.
What is Test-Driven Development?
Test-Driven Development is a software development approach where there are test cases developed to specify and validate what the implementation code will do. In short, test cases are created and tested first, and when it fails, then that's the time we write the new code to pass the tests.
The process of TDD starts with developing tests for every functionality of the product. We need to make sure that there is no implementation code added before the test is failing. You might be thinking, why write a failing test? They are useful for developers to keep the code simple because then the implementation code is focusing on passing the test only. This is also to avoid duplication of code. After the written code passed the test, now you can refactor the code to make it better.
Benefits of TDD
By applying TDD to your software development cycle, you’ll get some benefits such as:
Clearer Requirements
When applying TDD, you will make tests before the implementation, so as a developer, you will create such scenarios and have a better understanding of the requirements.
Simpler Code
As mentioned before, when you use TDD, you will focus on how to pass the test without overkilling the code with complexity. This will avoid developers from writing unnecessary lines.
Easier to Locate Errors
We use a unit test, which is a test for each of the small parts of the functionalities (e.g. methods). So when a test is failing after you write the implementation, you can easily find out which test is failed and that's where the bug is.
Keeping your Code Safe
Doing many iterations in the software development cycle means that are times when we modify our code due to the change of requirements. Using TDD will help you to avoid ruining your previous code from the newest changes.
TDD In Agile Development
Agile development has been well-known for its flexibility in accepting changes. As mentioned before, TDD is made for this! Applying TDD to agile development will minimize the possibility of a developer breaking code that is already running well when adding new changes.
Agile Development developers usually use these three kinds of commit message when applying TDD:
- [RED]
This commit message is used when we push the tests and expect a failing result due to the non-existence implementation code.
Here’s an example:
The image above is a unit test for expecting a certain text on a page and the type of widget used. We expect the test to fail because the implementation is not yet to be made. When you’re done, push the commit with the tag “[RED] <commit message>” like this:
- [GREEN]
After the tests are pushed, now you can start writing the implementation code to pass the created tests. Run the test locally and make sure they all passed, and then push the commits with the tag “[GREEN] <commit message>” like this:
- [REFACTOR]
In this step, you can refactor the code to make it better. You can also start applying clean code if you haven’t done it in the previous step. Make sure to push the commits with the tag “[REFACTOR] <commit message>” like this:
The refactor commit shown above is used to correct functionalities of a button like this:
The after code is created to redirect the button to a certain page and add an exception handling case where the field might be empty.
Code Coverage
When we talk about TDD and testing, the term “code coverage” might as well involved with the topic. So let's talk about it!
According to atlassian.com,
Code coverage is a metric that can help you understand how much of your source is tested. It’s a very useful metric that can help you assess the quality of your test suite, and we will see here how you can get started with your projects.
Basically what code coverage does is measures the lines of your implementation code covered by the test. So the bigger the number is, the better. We need to pay attention to this aspect because the code coverage usually used as a benchmark.
A 100% code coverage doesn’t make a perfect code, it just shows that all the code lines are covered by the tests. It can be done with a minimal test with minimal implementation, but we don’t want that. What you can do to make it better is to make all different kinds of scenarios for the tests and implement them to get higher code coverage.
That's all for the explanation of TDD, happy trying!
Reference:
