Highlights
Describing what TDD is and how it changed over the years
Bryan Finster joined us as our first hot join (at ~00h:15min)
Marc Weinberg joined us for a live TDD pairing kata (at ~ 01h:00m)
Coding and practical on-screen activities start at around ~01h:15m)
The Mysterious Testing Plan
More often than not, the testing plan is missing in most practitioners’ understanding of the TDD cycles. Perhaps it has to do with the red-green-refactor loop making it appear that there’s only three steps.
Or perhaps the thinking part of TDD is considered to be implicit. Kent Beck has recently reiterated this disconnect in the community. The right or wrong way may be leading us down the wrong track, but as the author of the book TDD By Example he described his preference for his canonical definition. I agree with this humorful characterisation by
accompanied by a visualization made by one of Kent’s community members:
Key TDD ideas by Bryan
I really try to lower the bar on entry on [TDD] because people either use “I'm working on a legacy system” as an excuse or they have fear that they can't do TDD on a legacy system.
When you're testing a legacy system:
The current behavior is tested in production. Not awesome, but it's true.
For your next change, test the behavior of the thing that you're about to change and then test that you can change it to what it should do next.
And then never push untested [new] code again.
Eventually you'll remove the legacy—because legacy is untested code.
If you enjoy these stream and recaps, consider sharing it with a friend
End-to-End Tests
Bryan in conversation with Denis and Adrian:
Bryan: You want my opinion? Because it's controversial.
—Mine's controversial too, so I don't think we can win here.
Bryan: Okay, so my opinion is that you have end to end tests because your architecture is broken. And if you need an end to end test, you put one in place and then fix your architecture and remove the end to end test.
That if you have clean architecture, and this is not a theory, this is how I work. Clean architecture. And then you can test each of the components and you can test the interfaces against virtual services.
And by the way, testing against the virtual service means you get to test more and better than you can against a real dependency because you can't control that dependency.
But if I can test that this thing behaves correctly and this thing behaves correctly and that they will talk to each other correctly, then as a, as an end to end test will work because I focus on the architecture make sure that we're not mutating value objects as they go across the network.
Live TDD Pairing with community members
The second half of our stream we Marc hot join our stream for a live kata. Adrian had the brilliant suggestion to do the 99 Bottles kata in typescript and we jumped straight in without much prep!
What you’ll see is an unscripted, first-time solution to the kata demonstrating live pair programming using TDD and requirements analysis.
I’ve extracted the core ideas into a shorter 15min video that I posted earlier this week on LinkedIn.
Conclusion
This stream was a dynamic back and forth covering a lot of ground on modern TDD basics. What’s your favorite part?
MODERN BASICS of Test Driven Development