<story><title>Testing Without Mocks: A Pattern Language</title><url>https://www.jamesshore.com/v2/projects/testing-without-mocks/testing-without-mocks</url></story><parent_chain></parent_chain><comment><author>thom</author><text>Once you’ve replaced each infrastructure dependency with some form of test double (whatever you call it) that captures state, broad tests are no longer slow nor do they fail randomly so I’m not sure I understand why you’d ditch them. Ubiquitous narrow tests are brittle in the face of most refactorings whereas broad tests care about things your users care about and usually persist across those changes. I’d always prefer the latter, though I’m happy to have both. A codebase without broad tests (or without explicitly modelled use cases that are ‘sociable’ with a broad range of dependencies anyway) is unlikely to describe what it actually _does_ anywhere and sounds like a pain to reason about.</text></comment>
<story><title>Testing Without Mocks: A Pattern Language</title><url>https://www.jamesshore.com/v2/projects/testing-without-mocks/testing-without-mocks</url></story><parent_chain></parent_chain><comment><author>djur</author><text>There&amp;#x27;s actually some good ideas in here. I wish it wasn&amp;#x27;t written in such a buzzword-heavy, consultant-y style. When advice includes so many Novel Proper Nouns I find myself checking my wallet.&lt;p&gt;My main quibbles are that these &amp;quot;Nullables&amp;quot; are still test doubles, just implemented in a way with different tradeoffs than typical mocking frameworks. Also, spies are still helpful when you&amp;#x27;re checking for side effects. I&amp;#x27;m not really seeing any alternative offered here for testing &amp;quot;does this code send 0, 1, or 500 emails&amp;quot;.</text></comment>