I feel like this distinction is arbitrary and unintuitive. A mock is literally just something that mimics something else. All "doubles" can be considered mocks. Claiming that mocks <i>insist</i> on call verification seems like a very forced categorization. If there's value in this distinction, maybe we need new terminology instead of asserting that everyone who's conflated "stubs" and "mocks" for two decades is wrong.<p>As a side note, verifying call patterns makes for terrible, brittle tests that cost far too much to maintain. This pattern is great for enforcing call patterns that truly that matter for, e.g, performance reasons (no unexpected cascade of DB calls), but is typically just a giant pain that provides little to no value, because instead of testing that the code does the right thing, you're testing that <i>it doesn't change</i>.
I often found that these terms are not very usefull when explaining the concepts of IoC in testing (which is essentially what they do) to colleagues who were unfamiliar with it. Programming in .NET I usually tried to use frameworks that avoided the terms, such as NSubstitute where you create an object by substitution:<p>var format = Substitute.For<IFormatCode>();<p>I haven't used it in a while but I remember that Rhino Mocks asked for ridiculous code like<p>var format = MockRepository.GenerateStub<IFormatCode>();<p>(Which one is it, a Mock or a Stub? And: Does it matter?)<p>I recommend Gerard Meszaros excellent book XUnit Test Patterns, he makes more fine grained distinctions between different aspects of testing. I liked his notion that you simply create objects that produce or react to "indirect input and output" (i.e. exceptions, opcodes, sideeffects) rather than "direct input and output" (which is what "arrange" and "assert" are checking). Mocks and stubs are only realizations of different patterns.<p><a href="http://xunitpatterns.com/" rel="nofollow">http://xunitpatterns.com/</a>
Every validation you do on a mock is an assertion on outside behavior that is in no way coupled with your test. If that behavior changes, your test is now false. Not failing. False. That concerns me.
This article is almost universally cited when a book or article on testing or TDD begins the inevitable discussion of mocks/fakes/stubs. But in real life, this is a distinction without difference. I have never once heard someone use the term 'mock' and be misunderstood because he/she should've used 'stub'.
How do you test your code that interacts with external components, like sending emails to a mail server or making an external API call without using some sort of test fake or stub? (using the definition of them from the article)<p>I'm new to TDD and refactoring legacy code for testability. With the code architecture I have it looks and feels like I need either a mock, fake, or stub.<p>I'm using an IExternalComponent interface as a parameter and for the concrete implementation I can either pass the real thing (it's non deterministic, this works if the service is up) or I can pass a test double that allows me to throw exceptions at will and force failure conditions to be tested.<p>Is there another way of doing this that I am missing?