[rspec-users] Mock and Stub objects

David Chelimsky dchelimsky at gmail.com
Thu Jun 11 09:36:28 EDT 2009

On Thu, Jun 11, 2009 at 4:39 AM, Amit Kulkarni<lists at ruby-forum.com> wrote:
> Matt Wynne wrote:
>> On 11 Jun 2009, at 08:17, Amit Kulkarni wrote:
>>> those objects.
>>> it
>>> be fine?
>> If you're writing the specs after you've written the code, you're
>> losing a lot of the value of mock objects.
> Actually i am writing specs before the code is written.I saw many
> examples especially in controllers they are using mocks.So i was bit
> confused regarding the same.
> Also Imagine the same situation where code is written and we are writing
> specs for that then is it necessary to use mocks?If Yes why since code
> is already written?

It's not a matter of necessity, but rather a matter of costs and
benefits. This is a very complex and subtle topic, which is one reason
a lot of people who avoid mocking do so. At some level, it is simpler
to not use any mocks or stubs anywhere. But if you choose that path,
there are a lot of benefits you're missing out on.

Steve wrote in his reply earlier in this thread that we don't want out
controller specs failing because the model is broken. But it's not
just when the model breaks. It's when the model *changes*.

Say, for example, that we've got a Widget model that has a required
name attribute, and an optional date attribute. We've got this in our
controller spec:

describe WidgetsController do
  describe "POST create" do
    context "with valid attributes" do
      it "redirects to the widget list" do
        post :create, :widget => {:name => 'Foo'}
        response.should redirect_to(widgets_path)
    context "with invalid attributes" do
      it "re-renders the 'new' template" do
        post :create, :widget => {} #missing the required name
        response.should render_template('new')

Now imagine that we're working on the model spec and we get a new
requirement that the date is required. So we write a spec:

describe Widget do
  it "requires a date attribute" do
    Widget.new(:name => 'Foo', :date => nil).should_not be_valid

That fails, so we add "validates_presence_of :date" to the model and
then the spec passes. Success! Except now the valid attributes case in
the controller spec fails because we've changed the meaning of valid
for this model. So you have to go back and change this and every other
example that creates a Widget without a date.

Now stubs/mocks are certainly not the only way to fix this problem.
You can use fixtures, centralized helper methods, object mothers, and
test data builders. These are all tools that help you centralize the
creation of objects, so when you do run into this sort of problem, you
only need to fix it in one place. But you still need to fix it once,
which takes your focus away from the task at hand. And you don't get
the speed savings you get w/ stubs/mocks. And you still get controller
specs failing when models are broken.

For the record, I generally use stubs/mocks in controller specs, but I
tend towards test data builders in model specs. But I'm also very
comfortable with all of these tools and am perfectly willing to use
test data builders in controller specs or mocks/stubs in model specs
when that is the better choice for a given situation. Really, I think
that's what we should all be striving for. Not so much "should I use
mocks or not," but "when should I choose to use them?"


>> Mock objects were originally devised as a design tool for use when
>> doing TDD. TDD stands for Test *Driven* Development, meaning that you
>> write the test before you have written any of the code. When you're
>> doing this, you want to be able to build the system piece by piece,
>> class by class, so you write tests for a single object at a time, and
>> use mock objects to assemble quick, lightweight sketches of the
>> surrounding objects that you imagine it will interact with when the
>> system is finished.
>>> Also since i am using the beta version Mocking Objects part is not
>>> there.And it is does not give clearcut idea from the topic Mock
>>> Objects.
>>> Also it will be very helpful if you can provide me a link or anything
>>> which can give me details of Mocks and Stubs.How to use it?When to use
>>> it..e.t.c
>> This is a big topic which is not going to be easy to explain over
>> email. Here is some more stuff for you to read.
>> http://www.patmaddox.com/blog/you-probably-dont-get-mocks
>> http://www.mockobjects.com/book/
>> http://www.jmock.org/oopsla2004.pdf
>> http://www.martinfowler.com/articles/mocksArentStubs.html
> Thanks a lot Matt for the above links.
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list