Rails - Nov 2005 - rake test_unit is deleting my pre-loaded test data

I am trying to set up my unit tests with a database that is already
populated with data.  I am noticing that the testing infrastructure is
deleting all this data before running my tests.  Presumably to start
from scratch and load fixtures.

So, I must be doing something wrong.  In test_helper.rb I have these lines:

 # Turn off transactional fixtures if you''re working with MyISAM tables
in MySQL
  self.use_transactional_fixtures = true

  # Instantiated fixtures are slow, but give you @david
  self.use_instantiated_fixtures  = false

   # The data we want is in the database already
   self.pre_loaded_fixtures = true



Any ideas what I am doing wrong?  Any suggestion on the best way to
accomplish this?

Thanks,

Dave

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 21, 2005, at 10:20 PM, David Clements wrote:
> I am trying to set up my unit tests with a database that is already
> populated with data.  I am noticing that the testing infrastructure is
> deleting all this data before running my tests.  Presumably to start
> from scratch and load fixtures.
>
> So, I must be doing something wrong.  In test_helper.rb I have  
> these lines:
>
>  # Turn off transactional fixtures if you''re working with MyISAM  
> tables in MySQL
>   self.use_transactional_fixtures = true
>
>   # Instantiated fixtures are slow, but give you @david
>   self.use_instantiated_fixtures  = false
>
>    # The data we want is in the database already
>    self.pre_loaded_fixtures = true
You don''t need this line.  Ignore the preloaded fixtures; they
don''t
do what they mean and will be deprecated shortly.

I also have a prepopulated test database.  All you need is to use  
transactional fixtures and omit any "fixtures :foo, :bar"  
declarations in your test cases.  I''m guessing you still have calls  
to fixtures.

Best,
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDg4oQAQHALep9HFYRAq/6AJ482SNHvShxcnmBnfWHvZjlbGHS2gCgoiUg
1TbWXKdFhscf0sE+NnHz944=n/gQ
-----END PGP SIGNATURE-----

On 11/22/05, Jeremy Kemper
<jeremy-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Nov 21, 2005, at 10:20 PM, David Clements wrote:
> > I am trying to set up my unit tests with a database that is already
> > populated with data.  I am noticing that the testing infrastructure is
> > deleting all this data before running my tests.  Presumably to start
> > from scratch and load fixtures.
> >
> > So, I must be doing something wrong.  In test_helper.rb I have
> > these lines:
> >
> >  # Turn off transactional fixtures if you''re working with
MyISAM
> > tables in MySQL
> >   self.use_transactional_fixtures = true
> >
> >   # Instantiated fixtures are slow, but give you @david
> >   self.use_instantiated_fixtures  = false
> >
> >    # The data we want is in the database already
> >    self.pre_loaded_fixtures = true
>
> You don''t need this line.  Ignore the preloaded fixtures; they
don''t
> do what they mean and will be deprecated shortly.
>
> I also have a prepopulated test database.  All you need is to use
> transactional fixtures and omit any "fixtures :foo, :bar"
> declarations in your test cases.  I''m guessing you still have
calls
> to fixtures.
>
> Best,
> jeremy

So it is an all or nothing kind of thing?  I can either use a
pre-loaded database or fixtures but not both?

Thanks,

Dave

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 22, 2005, at 4:59 PM, David Clements wrote:
> So it is an all or nothing kind of thing?  I can either use a
> pre-loaded database or fixtures but not both?
Yes.

pre_loaded_fixtures is for preloading your fixture files by calling  
Fixtures.create_fixtures directly; it is not for a preloaded database.

Preloading the database doesn''t offer you much if you''re using
fixture files anyway.  Why not just use transactional fixtures and be  
done with it?

jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDg85YAQHALep9HFYRAqVYAJ0apUexioYeF/2Ogc07cJo03du1CACgszeo
czJiNZ29S5ZDMOrkc0brew0=YCMm
-----END PGP SIGNATURE-----

On 11/22/05, Jeremy Kemper
<jeremy-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Nov 22, 2005, at 4:59 PM, David Clements wrote:
> > So it is an all or nothing kind of thing?  I can either use a
> > pre-loaded database or fixtures but not both?
>
> Yes.
>
> pre_loaded_fixtures is for preloading your fixture files by calling
> Fixtures.create_fixtures directly; it is not for a preloaded database.
>
> Preloading the database doesn''t offer you much if you''re
using
> fixture files anyway.  Why not just use transactional fixtures and be
> done with it?
>
> jeremy
I am not positive about the details as this task was just given to me,
however, the belief is that the foreign key relationships are complex
enough that populating the db through fixture files would be overly
complex.  Since we already have data for a test DB why not just use
it?

I still plan on using the transactional support.  I can right?  I
don''t want to purge and reload all the data for each run of the tests.

Dave

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 22, 2005, at 6:42 PM, David Clements wrote:
> On 11/22/05, Jeremy Kemper
<jeremy-w7CzD/W5Ocjk1uMJSBkQmQ@public.gmane.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Nov 22, 2005, at 4:59 PM, David Clements wrote:
>>> So it is an all or nothing kind of thing?  I can either use a
>>> pre-loaded database or fixtures but not both?
>>
>> Yes.
>>
>> pre_loaded_fixtures is for preloading your fixture files by calling
>> Fixtures.create_fixtures directly; it is not for a preloaded  
>> database.
>>
>> Preloading the database doesn''t offer you much if
you''re using
>> fixture files anyway.  Why not just use transactional fixtures and be
>> done with it?
>>
>> jeremy
>
> I am not positive about the details as this task was just given to me,
> however, the belief is that the foreign key relationships are complex
> enough that populating the db through fixture files would be overly
> complex.  Since we already have data for a test DB why not just use
> it?
I thought you just said you are using fixtures, but preloading them in
a rake task.  If you aren''t, how do you expect foobars(:fixture_name)
to work?  It uses a name from the fixture file which is not present in
the database.

> I still plan on using the transactional support.  I can right?  I
> don''t want to purge and reload all the data for each run of the
tests.
Yes.

For fixture naming, I just set some instance variables in my test''s
setup method:
   def setup
     @foo, @bar, @baz, @qux = Foo.find(1,2,3,4)
   end

You could also make a convenience reader like:
   def foos(name)
     Foo.find_by_name(name)
   end

jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDg9ovAQHALep9HFYRAjiFAKCOcbIXxTfJJj7+hKvAy+vK7PCawACeLFnD
JZyiJaT1Ilm/CNKRjHbu9xc=ovWc
-----END PGP SIGNATURE-----

> >>
> >> On Nov 22, 2005, at 4:59 PM, David Clements wrote:
> >>> So it is an all or nothing kind of thing?  I can either use a
> >>> pre-loaded database or fixtures but not both?
> >>
> >> Yes.
> >>
> >> pre_loaded_fixtures is for preloading your fixture files by
calling
> >> Fixtures.create_fixtures directly; it is not for a preloaded
> >> database.
> >>
> >> Preloading the database doesn''t offer you much if
you''re using
> >> fixture files anyway.  Why not just use transactional fixtures and
be
> >> done with it?
> >>
> >> jeremy
> >
> > I am not positive about the details as this task was just given to me,
> > however, the belief is that the foreign key relationships are complex
> > enough that populating the db through fixture files would be overly
> > complex.  Since we already have data for a test DB why not just use
> > it?
>
> I thought you just said you are using fixtures, but preloading them in
> a rake task.  If you aren''t, how do you expect
foobars(:fixture_name)
> to work?  It uses a name from the fixture file which is not present in
> the database.
>
Perhaps I am confusing some terminology here.  I have some tests that
do not indicate that they need fixture data.  The test assumes that
the test database is already populated with the data that the test
will work from.

After looking at the rake files,  I am seeing that it is the rake
dependencies of the task test_units that purge the test database.  And
since I don''t have fixture files,  the DB is basically empty as I run
my tests.  If I want to do it this way then I think I need to create
my own test_units task that does not have this dependency.

All of this makes me think that I am doing something "un-standard."

Dave

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 22, 2005, at 8:44 PM, David Clements wrote:
> Perhaps I am confusing some terminology here.  I have some tests that
> do not indicate that they need fixture data.  The test assumes that
> the test database is already populated with the data that the test
> will work from.
>
> After looking at the rake files,  I am seeing that it is the rake
> dependencies of the task test_units that purge the test database.  And
> since I don''t have fixture files,  the DB is basically empty as I
run
> my tests.  If I want to do it this way then I think I need to create
> my own test_units task that does not have this dependency.
>
> All of this makes me think that I am doing something
"un-standard."

Aha-- I do this too.  It''s nonstandard, but it works great!

Yes, you need to change your rake tasks.  Just make your test_* tasks
depend on the :environment task instead of :clone_structure_to_test.

Then it won''t touch your db before running the tests.

jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDhBCUAQHALep9HFYRAn8FAJ0XSqUHOPgsBDx2MmIG0QTEjmF2wwCglESo
JQsfnS7N1RtxiEgxZagRxa8=tsvK
-----END PGP SIGNATURE-----