Test Driven Development, or
TDD. Have you heard of it? Yes, I believe so. Do you practice it? No, I believe. I don't either. Usually I write tests AFTER the code itself. Today I want to talk about the specific angle of TDD — using TDD to architect your code.TDD concept is simple:1. You write your test BEFORE you write any code
2. Then you run the test — it shall fail 🛑
3. Now you write your code/feature
4. You did it right, run your test again — it passes ✅
5. Optimise your code
I continue (and finishing!) to read the "Modern Software Engineering" book, and the author has uncovered another perspective of
TDD to me. The purpose of this concept lies not in the assumption, that this way you are sure that your code is tested. Even bigger advantage hides, that if you do your development this way — you force yourself to write the code which is testable. And if you write code that is testable, there is a high chance, that it will be easy to maintain and extend this code. Why? Because if your code is testable, it's highly likely that you use inversion of control, loose coupling, modularity and other traits which we like to see in the good code.Profit.
⬛️ I remember once I've rediscovered UML and thought that it's great, you do not need to code to design applications. You can just draw diagrams and, this way, run thought experiments for all the ideas in my head. Now it may be even different — do not write an app, write tests and design your app this way. I'm going to try it out soon.
