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 too prefer just running whatever database in containers and mount them on a RAM-disk instead of mocking them out. SQL is too complicated to bother mocking. The hit in performance is negligible compared to developer time dealing with writing mocks and debugging them.
This whole mocking nonsense started to make tests run faster. You can still get fast tests with good code structure and tuned local database.
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 too prefer just running whatever database in containers and mount them on a RAM-disk instead of mocking them out. SQL is too complicated to bother mocking. The hit in performance is negligible compared to developer time dealing with writing mocks and debugging them.
This whole mocking nonsense started to make tests run faster. You can still get fast tests with good code structure and tuned local database.
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.
I avoid using the term “unit tests” now because it’s overloaded and likely to cause confusion.
Talking about testing of behaviors seems to lead to some ah-ha moments.