Phlip 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? > TDD does not do that. That statement is in direct contradiction to just about everything else I've read and striven for on the subject, at least if we're talking about fairly granular unit tests. Acceptance/functional/integration tests are another matter, of course. > 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? > > Given an object model Post -> Author -> Access, a test on the > Post->Author > relationship could conceivably ignore the Access. Right. > And a test on > Author->Access > could ignore Post. The -> goes nowhere; it is stubbed. Yes. No argument there. > > 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? > If our system were as coupled as a Vendor-Lock-In system, such as MFC, > we can't > just create one object. We have to pull in everything just to construct > and use > one stinking CEdit control. I'm not familiar with MFC, but I *think* I understand. However, it seems to me that fixtures for everything is doing exactly what you're saying *not* to do. > Don't do that. All objects should construct > cleanly > without their runtime dependencies, if you don't need them. I agree. That's why a test double should be sufficient. [...] > When you change the raw object, what part of the system forces you to > remember > to change the mock the same way? In many cases, an integration/functioanl test would break. In others...well, I'm not sure. I'll have to think about that. But this is a red herring: mocks and stubs (my original question) suffer from the same problem here. OTOH, I'm not sure it's appropriate to couple your unit tests to a live foreign object. Hmmm... I really appreciate being able to discuss these issues with those who know so much more about them than I do. Thanks for making me think! Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
