Don't Mock Yourself Out
Ask experienced Rails developers what they think about mock objects and some will say “absolutely awesome” while others “absolutely horrible.” The problem with both of those answers lies their “absolute”-ness.
Used appropriately, mock objects are a powerful design tool that can lead to highly maintainable applications. Used in the wrong context or for the wrong reasons, they can lead to painfully brittle test suites that do little to maintain confidence in an application.
In this talk, David Chelimsky will explore mock objects in the abstract and in the context of Rails. Questions include:
- What are mocks and stubs?
- When are they appropriate?
- When are they inappropriate?
- What are the benefits?
- What are the costs?
- Where are the pitfalls?
Attendees will leave this session with more insight into the motivations behind mock objects, and a better handle on when it makes sense to use them.
People planning to attend this session also want to see:
David Chelimsky
DRW Trading
David Chelimsky is the lead developer of the RSpec project, author of The RSpec Book, and also the lead developer at Articulated Man, Inc.
Comments on this page are now closed.














Comments
I enjoyed this talk. I’ve had the chance to hear David before so I always look for chances to see what he has to say.
I’m newer to this topic – so I appreciate the opening explanations and time spent bringing people up to speed. I gained some new insights. Thanks!
I really enjoyed the talk, and in many respects wish that the cucumber/rspec team had been available/invited to put together a tutorial to give the audience time to explore both the covered content and the issues David referred to as being much larger discussions in more of a first hand way. The examples provided were excellent illustrations, and I just wish there had been more time. Great talk.
David, good talk, enjoyed it but wish you had two hours, not one, to cover the information. DHH commented this morning that the community is now “leveled up” to a large extent. Perhaps having some talks that are going to assume a certain level of familiarity with a topic isn’t a bad thing. The “Don’t Mock Yourself Out” lead me to think that we’d be spending a lot more time at the later of the list of things in David’s talk description.
The session was good and presented basic information that was for the beginner and even the low-intermediate user.
This session and others seem to all have a problem of focused audience. Attendees are at all levels and are expecting different starting places in the sessions. David did a good job for the two lower level attendees.
The conference needs to provide two different levels of sessions. One for the beginner and one for the advanced. Otherwise we will have this problem of focus. If we as a group want to attract new Rails developers, we need to provide sessions for them also. Either that or state “no Newbies should attend”
I think that it would have been more useful to show more places where mocks (or stubs) are demonstrably the wrong way to do a test. Or where a stub is more appropriate than a mock. (The question at the end that led to the comment about “test spy” patterns ought to have made an appearance in the main talk.)
There was some really good stuff in this talk, unfortunately, all of it came at the very end: stubble and chains, with not enough time to actually cover them in any real way.
I think this talk should be more focused on either an intro to mocks and stubs, or talking about the use of new tools like stubble and chains. Would make the pace a lot less frenetic, both for David and for all of us trying to follow along…
-Brian (aka. @Mac_Zealot)
David, unfortunately I think you fell into the common RailsConf mistake—spending far too long covering remedial information for the 20% unfamiliar with mocking, and then being forced to speed through the meat of your talk that most of us wanted to hear.