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. 
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,
