On Jul 13, 2010, at 3:11 PM, Fearless Fool wrote:
In the spirit of peace love and understanding, I'll start by saying
that
I appreciate Marnen's philosophy, and I agree that "if the test has
any
potential of touching the database, it is *absolutely necessary all
the
time* to reset the DB to a known state."
But in my application, I have a few huge tables that are used
exclusively as reference data, are required for running any meaningful
tests and are never modified by the application.
For example, one is a TimeDimension table with one entry per hour
for 10
years (that's 85K+ rows). Each row is a "highly decorated TimeStamp"
which maps a timestamp to day of week as a string, whether or not
it's a
holiday and 17 other columns of dimensional goodness. It would take a
LONG time to set it up and tear it down for each test. In
comparison to
loading the table, MySQL's rollback mechanism is breathtakingly fast.
I think I recall this kind of question being answered before. The
gist was that you can define a 'facts' section of your database.yml
(similar to your 'development' or 'test' section) and create the
connection to the special 'facts' database for that model. It would
be unaffected by the initialization of the 'test' database.
The implementation is something like:
class Fact < ActiveRecord::Base
establish_connection "facts" if
RAILS_ENV == 'test' && configurations.has_key?('facts')
end
class TimeDimension < Fact
# ...
end
Then uses of TimeDimension in the test environment will use the
explicitly established connection. (Of course, you could do the same
thing regardless of environment, too.)
-Rob
[Before you ask why the heck a giant table is preferable to simply
using
the functions associated with Date and Time, I'll refer to you to:
http://www.ralphkimball.com/html/booksDWT2.html
http://philip.greenspun.com/sql/data-warehousing.html
]
Apart from the large "readonly" tables, I avoid preloaded fixtures for
all the reasons Marnen and others have pointed out: they're "brittle",
they tend obscure tests by separating "expected" and "observed"
results.
Etc.
But in this case, it really makes sense to preload the db with large
static tables. The alternative -- reloading the tables for every test
-- would not give me more insights about the business logic in my
application, and would be prohibitively slow.
Peace out.
- ff
Rob Biedenharn
[email protected] http://AgileConsultingLLC.com/
[email protected] http://GaslightSoftware.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.
