[rspec-users] Mocks? Really?

Dan North tastapod at gmail.com
Sat Dec 8 07:06:49 EST 2007

I prefer the mantra "mock roles, not objects", in other words, mock things
that have behaviour (services, components, resources, whatever your
preferred term is) rather than stubbing out domain objects themselves. If
you have to mock domain objects it's usually a smell that your domain
implementation is too tightly coupled to some infrastructure.

The rails community is the first place I've encountered stubbing domain
objects as a norm (and in fact as an encouraged "best practice"). It seems
to be a consequence of how tightly coupled the model classes are to the
database. I don't use rails in anger, and in the other technologies and
frameworks I use (in Java, .Net or Ruby) I never mock the domain model. It
seems unwieldy and overly verbose to me to have to stub properties on a
model class.

I usually use a builder pattern:

cheese = CheeseBuilder.to_cheese # with suitable default values for testing

The builder has lots of methods that start "with_" and return the builder
instance, so you can train-wreck the properties:

another_cheese = CheeseBuilder.with_type
toastie = ToastieBuilder.with_cheese(cheese).to_toastie # composing domain

In applications with a database, I then have a very thin suite of low level
integration tests that use "real" domain objects, wired up to a real
database to verify the behaviour at that level. Of course this is both slow
and highly dependent on infrastructure, so I am careful to keep the
integration examples separate from the interaction-based ones that I can

Maybe it's the way rails encourages you to write apps - where it's mostly
about getting data from a screen to a database and back again - that people
are more tolerant of such highly-coupled tests. For myself, I use builders
for domain objects and mocks for service dependencies whenever I can, and
have a minimal suite of integration tests that require everything to be
wired together. Using fixtures and database setup for regular behavioural
examples smacks of data-oriented programming to me, and stubbing domain
objects feels like solving the wrong problem.


On Dec 8, 2007 9:20 AM, Andy Goundry <andy at adveho.net> wrote:

> Thanks for all the feedback. Personally, i am working outside in, from
> views to models, so mocking does have its place. After lots of
> trialing, I am confident now that a Factory class can satisfy my need
> for using mocks and real models in different places. I define the
> characteristics of an intended model in the factory and ask it to
> return either a mock_model or a real one depending on my specific
> need. Once I've used in anger, I'll mail details of my implementation
> and experiences.
> Although I have played with story runner, I have yet to decide how
> I'll fit that into my development process. In fact, I love story
> runner, it's just I am not sure how much time I can afford to assign
> to tests on client work whilst I am still getting up to speed.
> As a note, I recently wrote a functional spec document for a client
> using the Given, When, Then approach for each use case, and the client
> loved it! It is a very clear way if writing specs.
> Andy
> On 8 Dec 2007, at 02:40, "David Chelimsky" <dchelimsky at gmail.com> wrote:
> > On Dec 7, 2007 8:30 PM, Priit Tamboom <priit at mx.ee> wrote:
> >> Hi!
> >>
> >>>> This is handy and keeps the view test isolated from changes to your
> >>>> models, but is that really the point?
> >>
> >> I was very confused first as well. It didn't make any point to me and
> >> I'm not using it at all. As far as I know, I take it as an optional
> >> tool to go nuts with views when needed. I will use it when some stuff
> >> in view becomes super important to be there. However as an one-band
> >> project I haven't feel this need yet.
> >>
> >> Second thing is about how you like to develop your stuff. As far as I
> >> know David start with Story -> Views -> controller -> model. I prefer
> >> to go this way: Story -> model/controller -> views. So now you might
> >> guess why specing views are nice thing when you go David's way
> >> up-to-down.
> >>
> >> Anyhow, mocking in controllers (and in views) makes much more sense
> >> now with story runner in the big picture. General stuff 'does it work
> >> at all' goes to story runner and specific low level stuff goes to
> >> spec. So it's up to you if you care about low level stuff in views.
> >>
> >> One thing what I still don't like so much is that rspec "force" you
> >> to
> >> develop things super vertically or otherwise your mocks will be out
> >> of
> >> sync very quickly. Correct me if I'm wrong !!!
> >
> > RSpec doesn't force you to anything at all. However, the agile
> > approach tends to be vertical slices in short iterations. Working
> > outside-in, using mocks, etc all ties in with that thinking.
> >
> > But rspec is certainly not going to throw errors at you if you decide
> > to write your entire model layer first.
> >
> >>
> >> Oki,
> >> Priit
> >>
> >> PS. somehow autotest does not pick up stories to run. I haven't yet
> >> investigate it why.
> >
> > This is by design. Autotest supports the TDD process - rapid
> > iterations of red/green/refactor. Having them run your stories too
> > would slow things down considerably.
> >
> >>
> >> _______________________________________________
> >> rspec-users mailing list
> >> rspec-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-users
> >>
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20071208/1fc89c90/attachment.html 

More information about the rspec-users mailing list