My Authors
Read all threads
Taking any one design technique "too far" is a really good way to learn about design! ...until it starts to feel like a silver bullet, at which point you risk frog-boiling yourself, contorting the entire design of your system to serve the silver bullet.
Case study: "mocking only hurts because your design is wrong." E.g., specifically: "Your module depends on 5 others, which it shouldn't. Fix your module dependency graph and the tests will be easy." Five is definitely not a huge number of modules to depend on.
If you focus on minimizing the number of interacting modules, it can easily lead to every module depending on ~2 others. Now the module dependency graph is artificially forced into the shape of a deep, roughly-binary tree, so we have to trace calls through 8 modules instead of 3.
Instead of letting mocks blindly dictate your design, you could: use a type system to make sure that the top module glues the other five together reasonably; push most conditionals into those submodules; add a few unit tests for those submodules; and add one integration test.
Now you have fewer tests; fewer modules; a mixture of absolute guarantees (from the type system) and checked executable examples (tests); and 5-50% as much total code as you'd have if you mechanically forced modules to have fewer dependencies and full isolated unit test coverage.
It's a bad idea to force every aspect of the system's design to conform to the needs of any one particular technique; mocks are just one common example.
(But seriously, doing a technique until it gets excessive and hurts is a great way to learn. Test everything with fully isolated tests until it hurts; try to encode every invariant with static types until it hurts; try using no types or tests at all and it'll definitely hurt!)
(I would love to hear an experience report of what happens when you adopt an absolute rule that the module dependency graph must take the form of a balanced binary tree at all times. I will not be trying it myself.)
red black module tree interview question joke
Non-joke reminder that programming is thinking in structure-as-such; it's not thinking in a particular programming language or in a particular tool. Also everything is graphs.
Missing some Tweet in this thread? You can try to force a refresh.

Enjoying this thread?

Keep Current with Gary Bernhardt

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!