Why TDD (Test Driven Development) ?
Have you ever work in a Tech Company and you found out code that you don’t understand because of incomplete test ? or even the worst part, the test is doesn’t exists ? or sometimes you feel not confidence when you want to change something that built by your (no longer exists) co-workers because fear of breaking things ? Well, this is common problems we often encountered when we don’t do TDD.
What is actually TDD ?
TDD stands for Test Driven Development. From this we could conclude that we develop something that driven by a test. We write the test before a single line of implementation code is written. That test will serve as a guideline what to build and to make sure we don’t break anything in the future that prevents the regular flow from working. We describe each unit of the system through a failing test and make it pass with an implementation first. Then, we can refactor it if necessary so that we can keep the cycle going over and over again. This is called Red-Green-Refactor cycle. This cycle will drive us to build all the pieces of our application with enough confidence that it will be robust and maintainable.
Why should we do TDD ?
By doing TDD, it make us to write an automated testing for our code and give us the confidence to make changes to the software. Additionally, it allows more agility for others developer who aren’t familiar with the details of the software to confidently modify the source code without introducing errors. So, why should we do TDD ?
- TDD can help to reduce bugs
The test is written to ensure comprehensive test coverage of the software, so bugs are more likely noticed in the test case. Tests also allow developers to work out potential issues before the application is ready to go into production. Because test suites are constantly maintained, they guarantee software quality.
- TDD can be our code guard
Confused what happen when we built feature A but feature B become unusable ? that won’t happen if we do TDD. The test can be functioning as a guard of our code because when somebody working on other feature that unintentionally changing behavior our previously written features our test could fail as it was not working as intended. Having a failed test means no green light to go on to production. So before continuing with the features, the other developers should know what changes that broke other features and could fix it. Also, it give more confidence to change the software without fear of breaking.
- TDD can acts as code documentation
Changing or refactoring other developers code is sometimes big pain because sometimes we don’t even know what does the code mean. in TDD, tests are written step by step. If you’re unsure of how a code works, go and have a read through the tests. With TDD, tests usually get written for different scenarios, one of which is probably how you want to use the code. So you can see the expected inputs a method requires and what you can expect as outcome, all based on the assertions made in the test. so the test could explain the intent of the code and this should be enough to be a code documentation. Also, refactoring code is a built-in step in TDD, we would end up with a much cleaner code. Code built with TDD tend to have less duplication, fewer edge cases that aren’t thought through, and a better overall architecture.
The test serves as a specification for what the code that will be written should do. As long as we are writing good stories, other development team should be able to build exactly what we asked for.
Conclusion
In summary, the importance of TDD cannot be overemphasized without trying it. From my point of view, TDD means less bugs, higher quality software, and increase development confidence, but on the other side the development time can a little longer. All in all, i think that is a good trade for the pros and cons and you should try it. Thanks for reading, in TDD we trust !