Test Driven Development (TDD)
TDD is a software development process where programmers has to create a tests before the actual function. This kind of approach is very common in many big-tech company, such as Google and Gojek. By creating tests before hand, programmers are opposed to develop a software that its functionality is not proven to meet requirements.
TDD flows, implementations, and benefit will be explored afterwards to give you a closer look about the world of TDD.
Tests are stories we tell the next generation of programmers on a project.
TDD Flow
TDD is a repetitive cycle, which only involves 3 basic steps. These steps can be broken down into the following:
1. [RED] Test Fails
As mentioned, we definitely need to create tests first. These tests are created in hopes to meet the expectancy of the software functionality. These tests are then committed as [RED] or failing, because there are no functions that can pass these tests yet in this stage.
2. [GREEN] Test Passes
After creating failing tests, we need to create the functions afterwards. The overall benefits of TDD can be seen here, as the program that will be created should only meet the expected criteria from the tests. This way, the program’s functionality will be managed and expected, preventing any unnecessary codes to be pushed. After the [GREEN] stage, the tests are expected to pass, making the codes fulfills the expected criteria
3. [REFACTOR] Refactor Functions
After creating functions that suite the criteria, there will be some dirty codes. In this step, we are going to implement refactoring to our project. From the refactoring step, the codes will not just be functioning through the criteria, but also readable as well.
TDD Implementation in Moodah POS
In our Project, we are also using TDD to guide our expected criteria in creating our software. From the image above, I created failing tests beforehand, then created the function that can fulfill the tests criteria afterwards. The “red x” and “green tick” mark also shows that the [RED] is still failing, and then passes when reaching [GREEN] step. In this case, I am using [REFACTOR] to make the codes look clean, as well as being more flexible with different input arguments.
Why do people use TDD?
Apart from joining the hype and looking cool, TDD also shows its benefits in a direct or indirect way. From my experience in using TDD in Moodah POS, I can break down the benefits into a couple points:
Backtrack to Previous Acceptance Criteria
When creating a new function, or develop an old one, there might be clashes between other established, connected program. With the help of TDD, I can check my function using npm run test to prevent clashes of functionality. If the tests shows that there are some old tests that fails, then there must be something wrong with my new codes.
Coverage Testing
This feature helps to track how much of our codes are covered from the tests. It is fairly common for developers to aim for high coverage, and checks whether the uncovered codes are not faulty. Using npm run test --coverage , we get to see individual files’ coverage and their uncovered lines(if any).
Conclusion
Utilizing software testing allows us to get a better angle to write our codes, and review the faulty ones. With larger and larger codes being handled, it is clear that professionals use TDD to create vivid codes. Hopefully, this article helps in guiding your TDD experience.
