[rspec-users] Mocks? Really?

Jay Donnell jaydonnell at yahoo.com
Wed Dec 26 13:44:53 EST 2007


My first email  sounded more certain that I intended.
I'm trying to work out my own views by throwing out
ideas in a peer review
fashion. 


> The integration test will die if you broke
> functionality.

I'm curious what you mean by 'integration test'.
With regards to rails, are your integration tests
always
testing the full stack and verifying against the
returned html/xml, i.e the verifying against the UI.
If so, I find it exceptionally harder testing
against the UI than testing against the controller
directly
and for many of my apps I don't do comprehensive UI
tests because they've bitten me too many times in
the past and I haven't figured out a better way to do
them. This is one of the reasons that I like having
my controller tests also be mini integration tests.


> By isolating the controller and doing
> interaction-based testing I find
> that I end up with simpler controllers and more
> simple objects.

Yeah, I've had this experience as well, but this
begs
the question, are these interaction based tests
really
tests? I mean, they aren't really testing anything
except assumptions that could easily be false. To me
it feels like a great design tool that isn't really
testing anything.


> I also prefer acceptance test driven development,
> which is TDD on top
> down development so interaction-based testing is
> important since the
> model is usually one of the last things I create.

I'm trying out this approach with a flex application
I'm making that has a rails backend. So far so good,
and the flex UI only talks to the rails portion via
restful calls. You can do top down by mocking the
backend with simple flat xml files which you then
implement after the UI is completed against the
mocks.

> I am not advocating using DI for the sake of DI, but
> it can be useful.

I agree, what I was trying to say is that it's the
exception rather than the rule for me personally.

> One of the things you didn't hit up is how you test
> objects which
> coordinate interactions vs those that do the work?
> Those branch/leaf
> object scenarios. How do you see testing those? Do
> see the separation
> of testing concerns as non-existent because only
> doing state-based
> testing will cause every failure (even when an
> object is working
> correctly, but the objects its coordinating are
> broken)?

This may be a matter of scale. The largest rails app
I've written is under 10k lines of production code
with a bit over 10k lines of test code. This is
relatively small, and at this level causing "every
failure" hasn't posed a real problem. One of the
lessons from the java world is that techniques which
are needed for large scale applications are often a
hinderance to small teams working on a much smaller
scale. 

Back to your question, how would a coordinated
object get broken? I can see this happening in a large
team, but with small teams it's rare. And, when it
does
happen it's nice getting notified from the
controllers test. Basically, my controller tests are
my
integration tests which gets back to my earlier
question about how you do integration tests. 


Jay


     


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 



More information about the rspec-users mailing list