We coded mostly and discussed things like. Coding starts at 22min:
🤬 Ranting on silly linkedin advice regarding TDD
🔧 Integration test should be based on the business domain, not on the technology used
🥜 The debate over what constitutes a "refactor" in the context of code changes
⛳️ Unhappy with our refactoring outcome, BUT it helped us find a bug!
💾 We are writing a database driver. Surprisingly difficult to distinguish integration tests from developer ones in this context
🙊 Naming tests can be difficult, but we used some simple tricks!
Test Composition
If you find you or your team struggle with similar issues it’s most likely caused by a lack of composability in your architecture. There is nothing wrong with the compiler or tools you are using—rather it’s a matter of language and intention.
“Test behavior not implementation” is a phrase commonly used in academic/training circles. Most engineers think interface vs. concrete class when hearing this. This is wrong.
Behavior means what are the rules and reasons the code exists? Like a bunch of lego pieces, how are they put together? Can they be tested individually? Behavior is about DOMAIN GLUE. Implementation is about the extreme sides of your architecture:
One extreme: Functions, parameters
The other extreme: Public API
These two capture the outside-in and inside-out approaches
But composability and behavior are something else. Composable behavior are independent constructs between the extremes that are combining several moving parts. Like taking apart lego bricks and reconstituting only a subset.
Bigger than functions, smaller than your public API. But without integration points—no out-of-process dependencies that would slow testing down.
These concepts are best described using a combination of Domain-driven design and behavior-driven development. Using plain language to describe why the system exists and what it can do for a user. Not how it from the perspective of a compiler, but rather how would you explain flow of information on an architectural, domain level?
Want to learn more?
Here a posts from 🔮 Crafting Tech Teams that go into detail on each of these topics:
Thank you 🙏
Thank you so much for your continued support. If you’d like a first-hand experience in getting your engineering culture to the next level while honing your leadership skills consider if coaching is the right solution for you.
TDD in Go—Pair programming with Jonathan Hall