Development Driven by Testing, What is that?
The process of developing things usually starts by designing, making the product then testing it to see whether or not the design works. Of course that process has been proven to work and have been used by most people for a long time, but what if there’s a different and maybe a better way to approach development?
What is Test-driven Development?
The technique is credited to be “rediscovered” by an American software engineer Kent Beck, he stated that the technique encourages developers to make simpler design and inspires confidence in development. It is the flow of the work that makes developers design simpler codes, it flips the normal flow by making developers write the tests before the implementations and treat the tests as some sort of checklist or guideline to what they need to do. This way the developers have a clearer sense of what to achieve which is to passed the tests that they made at the beginning.
The Flow
The flow of working with TDD which is an abbreviation of Test-driven development is by first making the test which is design to fail since the developer hasn’t code anything yet, in this stage the developers can commit the code with the [RED] prefix to mark the stage. After the test failed then the developer can start to code the implementation in the hopes that the test will pass, in this stage the commit prefix is [GREEN]. Then the next stage is refactoring, since the implementation is complete the developers can start cleaning up their code, to have a more dynamic and a code that doesn’t repeat itself. This step can be mark by the commit [REFACTOR] or [BLUE] prefix.
Why use it?
After understanding what is it and how it works, the next question that people ask are usually why? why bother changing the way we work? and the answer to that of course it’s not for nothing, there are a lot of advantages when working with TDD which some of them I’ve already mentioned when explaining what is TDD.
Simpler Codes
One of the advantages that I’ve mentioned is developers will write simpler codes in general, the cause of this is the mindset of the developers that they want to make codes that can passed the test. With that mindset developers will generally write codes that’s actually necessary which will make the code a lot simpler.
Inspires Confidence
Another advantage that I’ve mentioned is that working with TDD will inspire confidence in the development. When developers write their code, developers have thoughts about their codes having bugs and ends up not working. TDD can help developers to not be scared, since they code to past the tests it will be easier to know what’s wrong with their code, which lead to the next advantage which is easier to debug.
Easier to Debug
Since developers made their tests first, they can know with certainty that when their code have bugs they’ll know what to fix easily. When developers do implementation before tests, they’ll have to debug their code by either try catch or print methods. However, with TDD since they already have the tests they’ll just need to run the tests and find which test did the code not passed.
Making the Work more Efficient
When developers work with TDD, their requirement shifted from the features to the tests. Developers will focus more on passing the tests rather than making a fancy code, which means fewer lines of code. This is not only make the code cleaner in general, but also makes the developer’s work more efficient.
Safer Refactoring
Since refactoring comes after the code is finished implemented and tested, it will be generally safer to refactor some of the code to make it cleaner and more dynamic. Even if the code was someone else’s work, it will give other developer confidence to refactor someone else’s work knowing that they’ll have test cases to back them up if bugs start to appear.
Better Coverage
Normally after implementing their codes developers will start to write test cases to ensure that their code is error-free, but sometimes there’re a few lines that’s hard to get coverage and sometimes that line is not even necessary. With TDD the code coverage will almost always covered, since developers work to solve the test cases their codes are most likely covered.
More Documentation
Test cases can also act as a documentation for the developers, when someone inherited someone else’s work the developer can look at the tests as one of aspects to look at as a guide.
Implementation in my Team
We’re currently implementing TDD to our project, and we implement it exactly like how I explained it above. First we create the test cases and commit it to git with the commit message [RED] as the prefix, then it’ll be pushed to the pipeline where it’ll fail since the implementation hasn’t been implemented yet.
Then we’ll make the implementation that’ll fulfill the tests, after we’re sure that all the tests have been fulfilled we’ll commit it to git with the commit message prefix [GREEN]. Then we’ll push it into git and into the pipeline, normally the pipeline will pass.
After that stage we’ll continue to make changes to our code and strive for a more clean code, if we have changes to our code we’ll commit it to git with the [REFACTOR] and when it’s pushed into gitlab the pipeline should still pass.
Thank you for tuning in and reading my article! This is all very new to me, and it has been fun writing this article, hopefully this article have been informative and gave you more information about TDD.
See you on the next article!