[rspec-users] Mocking, changing method interfaces and integration tests

Pat Maddox pergesu at gmail.com
Fri May 25 18:38:02 EDT 2007


On 5/25/07, Courtenay <court3nay at gmail.com> wrote:
> Pat, I use rails' integration tests to test my whole app.  Usually I
> get lazy, and just dump my production data into the test DB and tell
> my SpiderTest to just spider every single page and tell me what broke.

That's cool.  I discussed what I think of the integration tests in my
response to David.  I'd be really interested to know if I'm missing
key benefits though.

> Also, I try to hide my database code behind methods, so 'find_by_user'
> would forever remain as a method and whatever DB code will always be
> hidden there.  To the controller, the actual fields I'm using are
> irrelevant.  When starting a new project I'll try hard to define a
> nice uncoupled interface between models and controllers. It's like,
> when you assume that the model's public methods will never change, you
> name them a bit differently.

Totally.  I did end up just writing a find_by_user method that
delegated to find_by_username, so I didn't have to change any of my
application code.  My concern though was that I didn't know it broke
in the first place because I was using mocks.  But you're right, had I
just written and tested find_by_user method instead of using the
dynamic finder, I wouldn't have run into that issue.  I'll be sure to
keep that in mind.  It goes along with "don't mock APIs you don't
own," and I certainly don't own the dynamic finders.

Pat


>
> I'm not much of a theorist, though, and much prefer to let others kick
> it out and wait for the dust to settle.
>
>
>
> On 5/25/07, Pat Maddox <pergesu at gmail.com> wrote:
> > This is something I've kind of struggled with over the past few months
> >  [1].  And just yesterday I made the decision to move away from mocks
> > in most cases.  That decision resulted from me changing a db column
> > name from 'user' to 'username', but one of my tests mocked a
> > #find_by_user method, so the test passed even though my code was
> > broken.
> >
> > Just to note, I've got ~7k lines of Rails spec code that uses mocks,
> > and tens of thousands that don't.  So I've used both approaches
> > extensively in multiple projects, and have formed the following ideas.
> >
> > I think David has a really good point about mock usage being related
> > to customer/programmer test coverage.  At this point, we don't have
> > any customer tests.  I also don't like the idea of relying on
> > heavyweight browser-based tests.  I want to be able to run rake and
> > know that my code works.
> >
> > Over the past week, I've converted a number of my controller tests to
> > use the real implementations instead of using mocks.  It was obvious
> > when I realized that in my controllers I'm concerned with state a lot
> > more than interaction - a request is made, some state changes, a
> > response is given.  I want my tests to prove that those state changes
> > are actually being made.  In this way, my controller specs act as
> > integration tests.  I do a *tiny* bit of mocking in controller specs,
> > in cases where I can't verify state such as making some notification
> > request to another machine in the system.
> >
> > I'm still using mocks quite a bit in my model specs, and I'm not quite
> > sure if I'll be cutting back or not.  Just going to take it a day at a
> > time and try to remove any pain.
> >
> > You've all surely read Martin Fowler's discussion about
> > interaction-based vs state-based testing.  One of the points Dave
> > Astels always hammers on about BDD and interaction-based testing is
> > that it's not testing, it's a design tool.  I've found that with mocks
> > I tend to arrive at a better design earlier on than I do without
> > mocks.  I've also found that I can't change the design very easily.
> > Mocks are coupled to the design of the code, not the behavior.  Aslak
> > says that state-based testing ain't BDD [3], but I disagree.  If I
> > can't refactor - changing the design of the code without changing the
> > behavior - that doesn't seem very behavior-driven to me.
> >
> > Mocks are nice as a design tool, but I've come to accept the fact that
> > creating a moderately good design early isn't as useful as having the
> > freedom to change my design later on.  I'm just not good enough to
> > come up with the perfect design the first time around.  My tests need
> > to give me the confidence to refactor.  And I need to be able to run
> > those tests quickly from the command line rather than having to start
> > up a browser, even if it's automated.  In that regard, mocks just
> > aren't for me, at least on my current project.
> >
> > Sorry for the length.  pat.should be_less_verbose
> >
> > Pat
> >
> > [1] http://evang.eli.st/blog/2007/4/9/i-think-i-might-not-get-mocks
> > [2] http://www.martinfowler.com/articles/mocksArentStubs.html
> > [3] http://blog.aslakhellesoy.com/2006/12/11/the-bdd-cargo-cult
> >
> > (for some reason it doesn't feel right to link to my blog and MF's
> > bliki together :)
> > _______________________________________________
> > 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
>


More information about the rspec-users mailing list