T·D·D
/ˈtɪdɪdɪd/
Good Morning/Afternoon/Noon/Night whenever you are! Alas, I must bring an unpleasant news right at the start by saying that this might be our last time seeing each other. While it pains me so, a wise person once said,
“Time’s arrow neither stands still nor reverses. It merely marches forward.”
Therefore, we shan’t waste any more time. The show must go on! This time I’m going to explain a bit about TDD, or the long way to say it, Test-Driven Development!
TDD
No references this time as TDD is literally an abbreviation, Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an automated test case usually designed to fail, that tries to achieve a desired improvement or new function, then creates the minimum amount of code to pass that test, and finally refactors and implements the new code in acceptable standards. Because we constantly create test cases for new functions and improvements, then create the bare-minimum amount of code to pass it, it’s most likely to be effective. It’s better like this than without. What? You’re still asking why you should be using TDD? Pfff. You know it’s fun, right? I’m not supposed to give my opinion, but give it a try, and then you can tell me if it’s good or not. Not convinced yet? Okay, I’ll cut you a deal. TDD is available for free, and that’s. A great. Price. If you’re still not convinced, I guess I have no choice but explain it.
Why you should use TDD
- Good tests make good documentation — both for you, your team, or anyone else that might find your project. Name your tests in a way that describes the tested function’s behavior, e.g. To test if your page implements the correct html, use the name “LandingPageHTMLTest”
- You’ll code faster. Even if writing a correct function implementation is difficult, pre-written tests will give you a clear target to hit.
- You’ll code correctly faster. Keep your test runner open to get continuous feedback on your work. This will get you to a correct implementation faster than coding an entire module at once and then testing it.
- You won’t forget to write the tests. Code without tests should make you uneasy, period. A comprehensive, passing test suite is reassurance to you and other developers that your code won’t break, hopefully.
- It provides a solid starting point for later work. If you pick a project back up after a few months, you’ll forget how most of the code works. Tests can be a reminder, and a tested code base can be a fallback if you suddenly break things.
- It pushes you to write cleaner code. Long, complicated functions are hard to test. Simple tests and clear descriptions will naturally lead to shorter, more readable application code.
- You’ll write more meaningful tests. With code already written, it’s easy to write tests that just pass instead of tests that confirm useful functionality. Imagine if your math professor only tested you on things you already knew — that wouldn’t be very useful!
These 7 outlines should convince you more and more to use TDD as you go further down from the 1st reason. Trust me, by the time you’re reading the 7th reason, you’re more likely to implement TDD on your project.
TDD Principles
As all great methods, TDD has basic principles. By combining programming, unit testing and refactoring, TDD is a practice that allows us to obtain a clean code, easy to modify and answering the expressed needs which remains the first priority when developing an application. The TDD has 3 phases:
- RED. First write a unit test in failure. The impossibility of compiling is a failure.
- GREEN. Write as soon as possible the production code sufficient to pass this unit test even if it means allowing the “worst” solutions. Of course if a clean and simple solution appears immediately, it must be realized but otherwise it is not serious the code will be improved incrementally during the refactoring phases. The aim here is to obtain as soon as possible the green bar of success of the unit tests.
- REFACTOR. It not only eliminates possible code duplications but also makes it possible to make changes in architecture, factorization, presentation. This refactoring concerns both the production code and the test code and must not modify the external behavior of the program, which is materialized by a test execution bar that remains green.
The implementation of these 3 phases is done within 5 main stages which constitute the TDD cycle. The stages are as below.
Conclusion
While it can be a bit hard to implement as we have to create individual tasks that cater to each and every new implementation/function, it is a process worth going to hell for, as after we implement TDD, we are sure to have clean code implemented and our project optimized! It not only helps you in the moment, but also in the long run. Let’s say you’ve finished one of your projects but didn’t implement TDD, and for your current project, you need some components that can be reused from your finished project. It would be The Valley Of Death you’re entering, son, as you haven’t implemented TDD, your code is sure to be dirty and therefore difficult to find the components you need. However if you implemented TDD, and the component you need is actually tested already, you can easily find it and take the snippet to use in your current project.
Welp, I guess this is the end. Why is the end always so sad? Well, can’t help it I guess. As I said before, “Times arrow neither stands still nor reverses. It merely marches forward”. This is goodbye. From me. Signing Off.
Good. Bye~
Some TDDs I’ve Done
Most are from other projects than UKM Indonesia though.
These are some of my TDD Implementations from a project where I made a LINE Chatbot. The tests are basically done to test if the bot can add service, remove service, update service, or view service.
