Marnen Laibow-Koser wrote: >> Mock almost nothing - the clock, the wire out of your >> workstation, and system errors. > > I was at a loss to understand this until I read the following sentence.
Only mock things that are too expensive to call directly. 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. TDD does not do that. > Stub everything that isn't what you're directly testing. If for some > reason you can't stub it, *then* mock it. > > Or more simply: > > If it isn't what you're testing, fake it! > > Is that a more acceptable method? No. I meant "expensive setup is a design smell". Given an object model Post -> Author -> Access, a test on the Post->Author relationship could conceivably ignore the Access. And a test on Author->Access could ignore Post. The -> goes nowhere; it is stubbed. Fixtures are among the systems that keep object models easy to whip out and use. 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. Don't do that. All objects should construct cleanly without their runtime dependencies, if you don't need them. >> and the mocks interfere with refactoring and decoupling. > > How? By making a test too dependent on another object's interface? But > don't stubs do that too? When you change the raw object, what part of the system forces you to remember to change the mock the same way? -- Phlip http://flea.sourceforge.net/resume.html --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
