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.
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