Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Mock or not to mock #9
Mocks are super, super useful if you understand and use them well. I think it's hard to use them well in rails, though; the framework encourages you to have giant classes with huge interfaces. They need to be used as a design tool (and they work wonderfully in that role).
I also think rspec-fire is incredibly awesome. I use it on all my projects these days, and it gives me an extra safety net when I refactor or rename a method.
Using test doubles doesn't mean you aren't testing "real behaviour" - it means you're only testing the behaviour of the subject under test. It means you're controlling the inputs to your SUT, and testing it in isolation from its real collaborators.
In doing so you gain useful design feedback about your object's collaborators (because you're forced to go through the hassle of representing them as doubles), discouraging coupling. You are able to make explicit the patterns of communication between your objects, improving your understanding of the way your objects interact, instead of just the values they compute. Even the simple necessity of getting your doubles into the SUT improves your design, because it encourages you to remove hard dependencies from your objects.
The use of test doubles is also not about fast tests, and spork is not a replacement for mocking. Spork is a kludge to get around the unfortunate fact that Rails forces your business objects to load the whole framework before they'll do anything. Fast tests are a happy side-effect of testing your objects in isolation from the behemoth that is Rails, but they are not the reason for using test doubles.
It's all very well saying "this section is opinionated", but a site that purports to represent a set of "best practices" really ought to fairly represent why and how test doubles are used before admonishing readers to avoid them.
"Mock or not to mock" is advice which, in the context of a list of best practices, probably does more harm than good since it doesn't actually state what the reader should - or shouldn't do. All it does is instil a sense of unease in the reader regarding mocks. And, as others have already pointed out, it has nothing to do with speed.
A much better piece of advice would be "use verifying doubles".