Hey Jeremy,
In the panel at RailsConf, you said that you don’t use fixtures but a
copy of the production database instead. Can you elaborate on how you do
tests this way (you also said it wasn’t that difficult 
)?
Thanks,
Joe
Joe R. [email protected] writes:
In the panel at RailsConf, you said that you don’t use fixtures but a
copy of the production database instead. Can you elaborate on how you do
tests this way (you also said it wasn’t that difficult)?
There is an ‘extract_fixtures’ rake task, which will do that.
HTH.
–
Surendra S.
http://ssinghi.kreeti.com, http://www.kreeti.com
Read my blog at: http://cuttingtheredtape.blogspot.com/
,----
| “All animals are equal, but some animals are more equal than others.”
| – Orwell, Animal Farm, 1945
`----
On 8/30/06, Joe R. [email protected] wrote:
In the panel at RailsConf, you said that you don’t use fixtures but a
copy of the production database instead. Can you elaborate on how you do
tests this way (you also said it wasn’t that difficult
Hi Joe. The basic idea: start with a test database full of fixtures and
rely
on transaction rollback between tests to keep the database clean.
Remove
all your fixtures :whatever lines from every test case. Use (clearer)
@bob
= Person.find_by_name(‘bob’) instead of the (convenient) named accessor
people(:bob).
If you already have .yml fixtures in place and just want to ditch their
declarations, then you can
Rake::Task[‘db:test:prepare’].enhance(‘db:fixtures:load’)
in lib/tasks/testing.rb. Then all fixtures are preloaded for all tests.
If you want to ditch the tyranny of fixtures files also, create a
‘pristine’
fixtures database and clone it to the test database whenever you modify
it.
In psql:
createdb -T myapp_fixtures myapp_test
Then use script/console fixtures (or a database browser) to create and
modify.
So, there’s not much to explain: stop using the fixtures feature; assume
the
data is there are ready to go.
jeremy
Thanks guys!
Joe