Honest reflections on what tests actually mean and what they cost
Sandi Metz's "Magic Tricks of Testing" conference talk should be mandatory viewing for every Rails developer. Not because it teaches you RSpec syntax or factory patterns. Because it answers the question nobody else answers clearly: what should you test and what should you not? Her grid -- incoming queries, outgoing commands, internal messages -- gives you a framework that eliminates at least half the testing debates teams waste time on.
If you maintain a large test suite, this talk will make you look at it differently.
An honest assessment of what a several-thousand-example test suite means: it means you value testing. It also means you probably have tests that are slowing you down. Not slowing the suite -- slowing refactoring. Tests coupled to implementation details. Tests that mock so aggressively they pass even when the code is broken. Tests that assert on structure instead of behavior.
I am not saying your tests are bad. I am saying that volume and quality are different axes, and this module is about the quality axis.
Over-mocking is the testing equivalent of technical debt, and it accumulates the same way: silently, comfortably, until one day you try to refactor a class and thirty tests break, not because the behavior changed but because you renamed a private method or changed the order of operations. The tests that were supposed to give you confidence to refactor are now preventing you from refactoring. That is worse than having no tests at all, because at least with no tests you know you are unprotected. Over-mocked tests give you false confidence.
The hardest lesson in this module: some tests should be deleted. Not fixed, not refactored -- deleted. Tests that test framework behavior. Tests that duplicate other tests at a different layer. Tests that lock in implementation details you want to change. Deleting tests feels wrong. It goes against every instinct. But a test suite is not a high score. It is a tool, and tools need maintenance.
Conclusion #
If you are the kind of engineer who already tests more than most, this module is not about testing more -- it is about testing better. The shift from "I test everything" to "I test the right things well" is one of the clearest markers of senior-to-staff growth. Your existing test suite is the perfect laboratory for this work.
Predictions #
-
You will delete tests from a suite you maintain after this module, and the suite will be better for it
-
The Magic Tricks grid will become your default framework for answering "should I test this?"
-
You will reduce mocking in your test suite by at least 30% and increase confidence in the remaining tests
-
Your test suite runtime will decrease even as coverage of meaningful behavior increases
-
You will start evaluating test quality in code reviews, not just test presence