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 _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users