G2Labs Grzegorz Grzęda
TDD rules
March 18, 2023
TDD is a hard piece of bread. Both for the Coder and for the rest of the World. Lets look at some basics of TDD so we could tackle with this concept 🕵️.
What is TDD
TDD is a set of three laws a Coder promises to obey. These laws are a scaffold, on which the Coder rests hers/his trust. This laws are (in order):
- You cannot write any production code unless it is to make a failing test pass,
- You cannot to write any more unit tests than it is sufficient to fail. Compilation failure is considered as a failing test,
- You cannot write any more production code than it is sufficient to make the failing test pass.
This may sound contradictory - you can’t write code so you must write a test. Yet not too much, just to make it all fail. Then just a little code to pass the test.
This locks you in a virtuous cycle:
Test - fail. Code. Test - pass. Repeat.
When you think about it a little more, you realise, that:
- you will progress in very small, atomic steps,
- there will be a lot of compilation and running going on,
- testing first requires more planning in advance,
- testing first covers the to-be code very deeply,
- many, many small tests, testing every single use case with every single special case.
Madness 😱…
Why use it?
After coding in such a cycle you will write lots and lots of code 🧾. A ton of it. Tens, maybe hundreds assertions over one module. Oh, modularity…
Writing tests covering (almost) entirely the code means, that:
The code will be decoupled. You need to write modules in a dismembered way so you could test it. Writing tests for a RESP method requiring a complete DB server running means that somewhere on the way you lied to yourself and took shortcuts. Also in embedded development - if you need an osciloscope or WireShark sniffing around, because the code needed to be fully deployed to the hardware. Decoupling is the way.
Little or no debugging. Extensive tests, frequent compilations and running means, that you will detect your (and others') errors faster.
The tests are the best documentation a Coder can desire! When you lear about a new framework or language, where do you go after reading the intro? To the tutorial, how-tos, examples, etc. The code is tested in every way. Every
else-ifis covered. Everyreturn 0. What if I try to invoke this method withnull? There is a test for that. But what if I run those two methods in reverse order? There are tests for that (or not - implicitly telling that there is no side effects taking place there).The tests can be run everywhere, by anyone. Before a merge to the main branch in the code repo. Before deployment. During CI/CD runs. Automatically, on the CI server. On your laptop, while you were on your way in a tran/airplane ✈️. Decoupled modules require minimal compilation environment.
The star of all 🌟. The tested code just run few seconds/minutes ago! So…. If you want to make some changes, you can do them without the fear of breaking stuff! The TDD gives you the ultimate power of the Coder: freedom 💪. If you change something and the code breaks - the tests will tell. If you make changes to the whole concent of the module, because your boss said so - the tests will tell. Which and where. And how deep is the damage. Of course, if you (and your team) promise to be honest. Honestly stick to the TDD mantra.
Why not to use it?
Why or when not to use TDD:
R&D, rapid prototyping, scouting for new ideas. This is actually the Coders frontier: to be an artist actually. The discovery of new stuff is a delicate, creative process. The rigid TDD loop will easily destroy that creative effort. The important part is - when you finally know how to do it, do it in the TDD fashion.
Over the hardware/specificity barrier code. Controlling a hardware output to drive an LED, writing fast kernel drivers, handling DMA transfers, complex floating point matrix operations using dedicated assembly macros…
Rockstar-grade 🎸 unicorn star-ups with rockstar developers. Either you don’t fit there, or don’t bother with that TDD gibberish. See you in 5-year, Mr. if-you-make-it-future CTO 🤣.
Conclusion
Do you need to use it? I think the answer should be simple…