TDD or DDT?
If you are reading this intentionally, and not after miss clicking post on my profile, I can guess that you at least have heard about TDD (Test Driven Development). TDD has given a bad representation around most programmers. You may use ‘TDD’ word in your programming joke. I find most TDD jokes are funny (yeah, it is). They think that TDD just holds them from implementing faster products, or takes too much time that doesn’t deserve to spend. Well, I’ve thought about it that way too. However, here I will show you how TDD going to save most of your time.
What is TDD?
TDD is a discipline in software development that forbids you to make implementation before you write the test first. TDD is coming from the Agile world, on it’s best practice. But nowadays, TDD is also used outside the agile context.
TDD Principles
TDD is combined only by writing a test, implement the code, refactor it, and so on. TDD can be written as 3 phases:
- RED. First, you are supposed to write the failed test. Slow down, you will implement it later.
- GREEN. Right after writing the failed test, write the production code that sufficient to pass the test. The code should be as simple as possible and don’t write any codes right after you pass the test.
- REFACTOR. Right, you should simplify your code. You may abandon it’s quality while focusing just only to make the test passed. Try to write it better. Remember, keep the test passed.
This cycle spends not more than 10 minutes. Take small iterations. Repeat the cycle until all features have been successfully completed.
TDD Rules
yeah, according to Uncle Bob, simply, there are only three rules in implementing TDD:
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
simple, right? I don’t think so.
I find myself struggling so much when adapting to TDD. Like it really slows me down, because I’m not used to implementing TDD. Then, I manipulate TDD with DDT (the parody version, can’t you take my joke?) by reversing the phases (most of you may have implemented TDD this way, admit it :) ), implement the code → write the test → push the test first. But after implemented the real TDD at some products, I figured that TDD is more than the way you test your code. the real TDD gives me MANY advantages that pay off all the struggles.
TDD Benefits
- Producing simpler high-quality code. By keeping the rules, you automatically satisfied 3 design principles at one shot: KISS principle (Keep it simple, stupid), YAGNI principle (You Ain’t Gonna Need it), and DRY principle (Don’t Repeat Yourself). after changing DTT to TDD I wrote simpler & effective code, instead of a long useless code that contains more code than it needed, it doesn’t satisfy rule number 3.
- Keeping you on track. By writing the test first, you will know where you are driving. Even if you are lost, you have GPS (TDD) to direct you back to the decided destination.
- Eradicates fear of change. If you need to refactor some lines in the future you don’t need to worry it doesn’t satisfy the functionality, because you already wrote the test. The test itself gonna warn you automatically by producing failure, when the test is not satisfied.
- High code coverage. Also by keeping the rules, your code should full of unit tests.
- Less time to debugging & reduced bugs. Whenever you get an error, you may easily debug and fix the code, because you write the code in the small iterations.
you still haven’t answered my question. How TDD will save my development time?
You might think that writing all the tests need a lot of extra code, and that takes much of your time. However, TDD has a learning curve. Firstly, you might need extra time in writing extra lines of code. So do I. If you practice and implement more TDD, you will climb the learning curve, and take less and less time to write extra tests. According to Kent Beck, instead of literally write unit tests for all implementation, you just need to write it for testing behavior. After around 2 years of implementation, you will find it simple to write extra tests.
How I implement TDD in Advokasimu
Mostly, I use Widget Tests because there is not much input in my feature. In this example, I’m supposed to implement a widget that contains widgets named ‘Bar Navigasi’,’Beranda’, and ‘ Ajukan Kasus’.
after that, I add and commit it with a message ‘[RED-Farihin] Add test for manualMain’. The test failed. Here, then I implement the BantuanPage() as a statefulWidget.
Then, I run the test, and it passed the test. Here, I should stop implementing more code. I move to the next step, where is REFACTOR. However, as you can see, this widget code is in good shape and doesn’t need to be refactored. So, the phase is done, and I can continue to write another test for the rest features.
Conclusions
After all, TDD is good and always good to be implemented. It may change the way you fix some problems or the way you look at some complex things. One thing that you should remember, the more you code in TDD, the more you find it easy because you are going to be at the peak of the learning curve. Take it easy, and enjoy your learning progress! :D
