?How do you enforce meaningful tests on a small team without coverage requirements or code review being the gate?

On an HN comment thread about Stryker mutation testing, commenter manquer described their stack for moving beyond coverage as the quality metric: investing heavily in static and dynamic analysis aspects — a lot more linting rules than ever before, also custom rule sets that do more org and project level validations; harder types enforcement in type-optional languages; beyond unit tests — test quality coverage tooling like mutation testing (stryker) and property based testing (quickcheck) if you can go that precise; much more dx scripts and build harnesses. The pattern: rather than fight bad tests through process (coverage thresholds, mandatory review), layer multiple independent signals that bad tests can’t simultaneously fool — mutation testing flags tests with no assertions, property-based testing flags untested input domains, strong types catch entire bug classes at compile time. Each signal alone is gameable; the stack is much harder to game without writing genuinely useful tests.

Same HN test-quality discussion, commenter vlovich123 offered a contrarian view: “I view all my code through end to end tests and use very few mocks. If I need a mock/fake for things that aren’t external to the code (eg I/O to network services), it usually means I haven’t designed my code modular enough and refactor.” His argument against heavy mocking: “all fakes (of which mocks are a subset) means you’re reimplementing your real code with a reimplementation specific to your test suite, which means your test suite isn’t providing coverage and now you have two codebases to maintain hidden in one.” The pattern, alternative to test-quality tooling: design tightly around external boundaries, test through end-to-end paths only, treat any need for internal mocks as a code-design smell. Quality signal becomes “do the e2e tests pass when behavior changes” instead of “how thorough are the unit tests.”

A Facebook engineering research paper (“What It Would Take to Use Mutation Testing in Industry”, arxiv 2010.13464) studied 26 developers using mutation testing in their workflow. The empirical finding: “24 of 26 developers expressed that mutation testing exposed a lack of testing,” and “almost half would actually act on the mutant presented to them by adapting an existing or creating a new test.” What makes mutation testing stick (vs coverage, which gets gamed): a surviving mutant is a concrete, actionable artifact — a specific source-line mutation that passed all your tests silently. Coverage tells you you should write more tests (vague, gameable with assert(true)); mutation testing tells you “this exact mutation passed silently, fix it” (specific, hard to game without genuine assertions).