Marnen Laibow-Koser wrote: >> We are not writing QA "Unit Tests" - the kind CPU manufacturers write. >> They need >> pure isolation between units, so when a test fails it only implicates >> one unit. > > Aren't we, though? What's the point of a test that doesn't tell you > what failed?
Under TDD, the element that failed must be among your recent edits. Therefor, tests are free to cross-polinate any of your modules together... >> No. I meant "expensive setup is a design smell". > > Then I guess I shouldn't be using Rails. I don't know how to test > anything based on ActiveRecord without reasonably expensive (in dev > time, anyway) setup. What am I missing? I don't mean this is expensive... foo = foos(:my_foo_fixture) ...I mean a zillion lines of pure clutter, building object after object and glueing them all together just the right way. That's expensive. >> Fixtures are among the systems that keep object models easy to whip out >> and use. > > Why not mock/stub model objects instead? I don't see a single benefit > from using fixtures, except that the setup expense is shifted from the > developer (lots of mocks) to the computer (excessive DB access resulting > in *slow* tests -- see Asynchronous Unit Testing antipattern). Is there > a third way that I'm missing? Better the computer is slow than the developer. That's orders of magnitude difference there. If your tests get too slow, install CruiseControl.rb for a build server. -- Phlip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
