Fearless Fool wrote: > Marnen Laibow-Koser wrote: >> [snip] >> Sent from my iPhone > > Wow - that's some agile thumbs you've got there.
I take the "agile" part of my job seriously. :D > > Yes, I could create mock classes No one is talking about mock objects, exactly. The objects you'd be creating with factories would be real AR objects, with real DB records behind them. There just wouldn't be 85,000 of them. Think about it: no test case is going to touch more than about 5 records maximum. You're just not creating the 84,995 you won't use. > that fake the data for exactly the > items I need. But: > > Since I already have the static tables (and have tested them), wouldn't > that be analogous to writing a Math::sin(x) function that is defined > only for specific values of x? Sort of. And that's a good testing practice: Math::sin is already well tested, so you don't need to test it further. So don't incur the overhead of calling it. Now, for a cheap function like sin, the difference in performance is trivial. For 84,995 unnecessary records, the difference is not trivial. > > To extend the analogy, Math::sin(x) is not part of the business logic of > my app, and I should not be testing it any more than I should be testing > whether or not :belongs_to generates the correct methods in > ActiveRecord. Correct. So don't bother calling it in your tests -- or in the analogy, don't bother testing your already tested gargantuan constant table. > > In these circumstances, I'd maintain that I'm MORE likely to introduce > errors in my tests by writing mock classes when stable, proven data > already exists. You're not writing mocks. And you'll be *less* likely to introduce errors, because you know that your specially crafted test data has exactly the properties that your tests need it to. With crafted test data, you're testing your application. With your whole constant table, you're testing your constant table -- which you say you've already tested -- not your app code, and you're working harder to do it. There's no advantage to this approach, and several disadvantages. Don't do it. > > Can't you just be happy that I'm not using fixtures now? :) But you *are* using fixtures. You may not be using the Rails fixtures mechanism, but you're still using brittle, permanent test fixtures instead of the flexible crafted test data you should be using. This is a terrible idea. There is not a single reason to do it that way. Do not do it. > > - ff Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] Sent from my iPhone -- 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.
