A Sprint in a Life of Test Driven Development
Hi! My name is Azka and this is a little bit of Test Driven Development (TDD) in Go.
TDD is a software development flow where it relies heavily on tests and requirements.
In a nut shell, TDD flow is the following:
- Gather requirement
To create a test in TDD, we want to make make sure the test to cover all possible input and outputs. That’s why we need to gather the requirement as best as we could, but not over doing it. Why you’d ask? Because Agile. - Create tests
The tests we create will need to follow the requirements we gathered before. Make sure the test contains no errors so that the implementation can be done smoothly. Here’s some small example of positive-negative test.
- Create implementation
As simple as it sounds, it’s not. The implementation will need to follows the tests (given the tests is correct). The implementation can be tedious if the tests has some errors and problems. - Refactoring codes
After we implements the code, sometimes it’s kinda messy and maybe still have some errors because it doesn’t follow the test. In this stage we correct it all and do the finishing.
Those are the flow of TDD that will be done repetitively. Each repetition has it’s own requirements, tests and implementation. And also refactors.
RED, GREEN, REFACTOR!
There are implementation of TDD, which is Red, Green, Refactor. This paradigm is what we used at Yuk Recycle as commit message tag. Here’s brief explanation of the paradigm:
[RED]is the tag used when the test is first created.[GREEN]is the tag used when the implementation is done.[REFACTOR]is the tag used when implementation needs some refactoring.
Why TDD?
We can develop our software just fine without TDD. Why using it now? Well there are few reasons.
When we code our software without TDD, we code while thinking. This could results in quick and plenty of context switching in our brain. We need to switching back and forth between the requirements and its implementation, and then testing it locally and fix it if there are any bug.
By using TDD, we do all the thinking first, defines our needs and requirements. After everything is clear and sound, then we code the implementation. This results in faster, more efficient and less misunderstanding or miscommunication between us and anyone else, because we could confirm our ideas and understanding of the requirement.
Other reason to use TDD is because we are lazy. Or atleast most of programmers I knew. If we don’t implement the test first, we might not ever going to. TDD forces us to implement the tests first, so in the future when we need to migrate our code or do some refactoring, we could use the tests to make sure our code run just fine after the “surgery”.
Well, hope it gave you some insight.
