Great developers need to know why they do what they do. Only then can they hope to apply, adapt, and even drop their practices in the context of each situation. Unfortunately, very few developers can clearly articulate why they do (or don't) use test doubles—be they mocks, stubs, fakes, or spies. This talk aims to raise the level of discourse on this topic. By better understanding why we use test doubles, we can write faster, clearer, and more informative test suites; even if it means choosing to never use a stub or mock again!
Many argue "mocks suck," because the resulting test won't be realistic enough to gain any significant confidence that their code works. Others use mocks to control the outer boundary of a test's execution from expensive, hard-to-setup dependencies (e.g. by faking a database or network resource). Others still see mocks as a "setup of last resort", using them to manipulate what would otherwise be an integration test in order to reduce the pain of hard-to-test situations. Finally, some developers use test doubles in place of nearly every dependency in every test, and their reasons are probably the most poorly understood of them all!
This talk will provide a broad-stroke survey of the different ways developers use test doubles, with the goal that we leave with a more sophisticated means of communicating on the topic. The talk will also provide practical guidelines for how adherents of each of these varying philosophies could better use (or avoid) test doubles. Finally—if the audience is kind—I'll share my own opinion on how and why I prefer to use test doubles (and maybe a little on what I learned writing my own test double library, "gimme").