TDD enthusiasts and rookies tend to miss the point of TDD. It's about writing a test plan and thinking about behavior from the consumer's perspective. This is the essence of the B in BDD. *Then* we do TDD to help us stay on track and focus on one iteration at a time.
So if I were to re-write your last list in the way that I tend to focus during coaching:
1. Write down the nouns and verbs in a system
2. Write a list of names for the next 3-4 tests. This is your test plan (or behavior contract)
3. Write test - this implements the behavior contract
4. Decide on public API
5. Write implementation - this solidifies the behavior implementation
6. Refactor tests if your original plan doesn't make sense anymore. Otherwise, refactor implementation to continue moving forward.
P.S.: "To balance speed of delivery with delivering higher quality" — TDD doesn't speed you up per se. It slows you (the developer down). What TDD allows is that it speeds up everyone around you that is part of the same value stream.
A TDD post I agree with (who knows me, it's not happening often). Thanks Mike!
Getting the big picture right is always the most valuable piece of testing. I like to run an integration suite with all databases and Kafka in TestContainers. It's not that much slower but covers the microservice end-to-end with the specific implementation checks that sometimes matter. And saves time needed for re-writing tests for integration.
Great @Mike!
TDD enthusiasts and rookies tend to miss the point of TDD. It's about writing a test plan and thinking about behavior from the consumer's perspective. This is the essence of the B in BDD. *Then* we do TDD to help us stay on track and focus on one iteration at a time.
So if I were to re-write your last list in the way that I tend to focus during coaching:
1. Write down the nouns and verbs in a system
2. Write a list of names for the next 3-4 tests. This is your test plan (or behavior contract)
3. Write test - this implements the behavior contract
4. Decide on public API
5. Write implementation - this solidifies the behavior implementation
6. Refactor tests if your original plan doesn't make sense anymore. Otherwise, refactor implementation to continue moving forward.
P.S.: "To balance speed of delivery with delivering higher quality" — TDD doesn't speed you up per se. It slows you (the developer down). What TDD allows is that it speeds up everyone around you that is part of the same value stream.
A TDD post I agree with (who knows me, it's not happening often). Thanks Mike!
Getting the big picture right is always the most valuable piece of testing. I like to run an integration suite with all databases and Kafka in TestContainers. It's not that much slower but covers the microservice end-to-end with the specific implementation checks that sometimes matter. And saves time needed for re-writing tests for integration.
I think the idea that we test behaviour not 'units' is key to moving the TDD discussion forward.
Personally I like TDD as I'd rather write my requirements in code - it's more precise - and in a testable way.