How to run unit tests w/o first blowing away test db?

fearless_fool · July 13, 2010, 11:38pm

Rob B. wrote:

On Jul 13, 2010, at 4:58 PM, Marnen Laibow-Koser wrote:

difference from production, more general hassle.

I still maintain that the right answer is not to test with all 85,000
records. Just create what you need for a particular test.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Perhaps you missed the part about this being a data warehouse.

I didn’t miss it. I don’t think it’s particularly relevant to testing
approaches, though.

It’s
probably already a separate database.

The OP has given us no reason to believe this.

Technically, it’s just a
separate schema within a database. And why does this have to be
different from production?

Because as far as we know, the OP is using one database for production.

If this is truly read-only data, then
production or any environment can use exactly the same technique. (And
multiple environments could use one golden copy of that reference
data, too.)

That’s certainly true.

I still think, though, that all this runs into the expensive setup smell
that we generally try to avoid when testing. Your points are valid for
production, but no test environment needs 85,000 reference records.

-Rob

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

fearless_fool · July 14, 2010, 1:10am

Marnen Laibow-Koser wrote:

[snip]
Sent from my iPhone

Wow - that’s some agile thumbs you’ve got there.

Yes, I could create mock classes 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?

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.

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.

Can’t you just be happy that I’m not using fixtures now?

ff

fearless_fool · July 14, 2010, 4:03am

Fearless F. 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,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

fearless_fool · July 14, 2010, 4:39pm

Who cares? Just generate a TimeDimension record that has the properties
you need for the particular test. If that means saying Easter fell in
December, that’s perfectly OK.

So your test is running fine when Easter fells in December…
and then you are going in production with your application,
you will have a lot of fun ;-))

Seriously, I too prefer to have some realistic test data and no
artificially
created test stubs, which have some assumptions about reality which
often fails…
phone numbers will always have seven digits and surnames will never
include a hyphen and Easter will always be in December…

My 2cts

Klaus

fearless_fool · July 14, 2010, 5:04pm

Klaus-dieter Gundermann wrote:
[…]

Seriously, I too prefer to have some realistic test data and no
artificially
created test stubs, which have some assumptions about reality which
often fails…
phone numbers will always have seven digits and surnames will never
include a hyphen and Easter will always be in December…

Then you’re doing your test data wrong. The point of crafted test data
is that you can test what happens with an eight-digit phone number –
even if all your real data has seven-digit numbers. Be imaginative
before your users are. And if your users do somehow discover a bug
before you do, make a test case out of it.

My 2cts

Klaus

fearless_fool · July 14, 2010, 5:09pm

Klaus-dieter Gundermann wrote:
[…]

Seriously, I too prefer to have some realistic test data and no
artificially
created test stubs, which have some assumptions about reality which
often fails…
phone numbers will always have seven digits and surnames will never
include a hyphen and Easter will always be in December…

Then you’re doing your test data wrong. The point of crafted test data
is that you can test what happens with an eight-digit phone number –
even if all your real data has seven-digit numbers. Be imaginative
before your users are. And if your users do somehow discover a bug
before you do, make a test case out of it and put it into your future
crafted test data.

My 2cts

Klaus

fearless_fool · July 14, 2010, 4:38pm

insert the following code to your Rakefile

Monkey patch Rake :

Rake::TaskManager.class_eval do
def remove_task(task_name)
@tasks.delete(task_name.to_s)
end
end

before the line require ‘tasks/rails’

The create a new file test.rake under Libs/tasks :

Rake.application.remove_task ‘db:test:prepare’
namespace :db do
namespace :test do
task :prepare do |t|
puts “\nData in the test database will not be deleted !!!\n”
end
end
end