If you’re building anything more complicated than, oh, a simple “ ” app, odds are that you’re going to end up with dependencies (•). These dependencies can vary all over the place, from access to system resources (How d’you think the “ ” actually got to your screen?), other components in your system, external resources, outside applications, and so much more. What’s worse is that Hello World! Hello World! the dependencies might be under development too even if they’re stable, you might not have everything necessary to access them (e.g., the auth framework to get at S3) and even then, you might want to test specific responses that you can’t guarantee (it needs to always fail. Or succeed. Or randomly based on a PRNG) And that’s where comes in, where you essentially fake your interactions with the dependencies, so that you can go about implementing stuff without depending on, well, your dependencies.Which is all well and good, and actually kind of intuitive when you get down to it, with one caveat — you’re likely to hear the terms , , and used somewhat interchangeably when you get around to googling. mocking your Mocks Stubs Shims Me, I tend to stick with the following semantics. You may or may not choose to use these, but whatever you go with, be sure to make sure that you have agreement with everybody else on your team. Also, document it for the sake of future team members, as well as future you!.(Or heck, you may go down the “ ” approach to existence. Just as long as a you have a consistent definition of what you mean by “ ” 😆) Mocks are a Code Smell, #JustSayNo Mock : A full-on stand in for the dependency, that replicates most or all of the behavior that you actually give a s**t about. These can actually get somewhat hairy (hence the “ ” crack above), since, , you basically need to track/replicate the functionality of the dependency. Then again, if you get a good mocking setup in place, it can be truly invaluable.The key, however, is that you interact with the mock in exactly the same way that you interact with the dependency, via APIs, interfaces, messages, or whatever. Mocks Code Smell in extremis can : These are extremely simplified versions of , which typically just return a set of hard-coded values, and/or fail, again, in simplistic ways. Think of the Stubs ←→ Mocks spectrum as one going from minimal functionality to full functionality, as shown above. You interact with the stub exactly the same way as you interact with the dependency (APIs, interfaces, etc.).Stubs are particularly useful for testing out your interfaces to the dependency, as just getting things going (hard coded responses are better than no responses!) Stubs Mocks : Sometimes you just don’t have the ability to create a or a , either due to to time constraints, complexity, or just lack of resources. In those cases, you might end up sliding in some code that basically acts as if you are interacting with the dependency. The key with though is that you use the interfaces — APIs, messages, etc. — that you usually would to get at the resource. For example, if you needed to retrieve something from S3, you just bypass the entire S3 interface, and just grab the object from a local file. Shims Stub Mock Shims don’t , in my experience, have been responsible for more chaos than I can shake a stick at. They create detours in your code, detours that can lull you into a false sense of security, or worse, detours that you forget you had in there. Use them with care, and only when you absolutely need to (and yes, there are times when you will!) Shims So there you have it — vs. vs. ! Mocks Stubs Shims ( This article also appears on my blog )
