Today I got reminded of a great video of GeePaw Hill about the “Five Underplayed Premises Of TDD”.
1. The money premise:
When writing tests, we don’t do it for the art of it or other moral reasons. We do TDD because it lets us build more features faster.
2. The judgement premise:
There’s no one-size-fits all approach to quality software. Developers applying TDD use human judgement while building `software systems.
3. The chain premise:
We prefer testing very tiny subsystems that make up our larger system. Why? Because small tests are not only easier to read, comprehend and write, but also execute a lot faster than large-scale end-to-end tests. This is a preference, not a hard rule.
4. The correlation premise:
The internal quality of the code for a system is directly correlated to the productivity of the developers working in this code base. They go up together, and they go down together.
5. The driving premise:
Tests and testability help drive the design of a system. A code base that is highly testable exposes certain characteristics that are generally considered as good design. People new to TDD often resist the idea of changing their design to facilitate tests. However, this is inevitable when doing TDD. This how this small practice drives the design.
These 5 premises are at the foundation of every step a developer using TDD makes. Check out GeePaw’s video if you want to learn more. The best 10 minutes you’ll probably spend this week. I promise 😄
Top comments (1)
I think TDD is a concept to aspire to, no to execute blindly. That is why I'm going to list the dark sides of the premises.
I go for a more pragmatic approach.