Forum: Ruby on Rails Help preloading test fixtures

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ccfe7d097475a32dc3ff78d6fc42c852?d=identicon&s=25 List Recv (lstrecv)
on 2005-12-07 07:26
I'm trying to use preloaded test fixtures + transactions.

I wrote a rake script to load the test database with all of my fixtures.

*BUT* when I use the fixture command, rails still inserts the .yaml
files into the db.  If I don't use the fixture command, the .yaml files
aren't accessible to the test methods.

(I tried setting use preloaded fixtures , but I may have done this
wrong).

Could someone explain to me how to tell rails to NOT insert the yaml
fixtures into the DB, but to nonetheless make them available to my test
classes?
Ccfe7d097475a32dc3ff78d6fc42c852?d=identicon&s=25 List Recv (lstrecv)
on 2005-12-11 02:58
If anyone needs more information to help answer this, please let me
know.

I'd really like to get this working!

lstrecv wrote:
> I'm trying to use preloaded test fixtures + transactions.
>
> I wrote a rake script to load the test database with all of my fixtures.
>
> *BUT* when I use the fixture command, rails still inserts the .yaml
> files into the db.  If I don't use the fixture command, the .yaml files
> aren't accessible to the test methods.
>
> (I tried setting use preloaded fixtures , but I may have done this
> wrong).
>
> Could someone explain to me how to tell rails to NOT insert the yaml
> fixtures into the DB, but to nonetheless make them available to my test
> classes?
Cb610750ee94ca103aef4b2dc7b1b768?d=identicon&s=25 nicholas.stuart (Guest)
on 2005-12-11 15:13
(Received via mailing list)
Could you explain why you would want to do this? If the test fixtures
get loaded automatically, as they do normally, why do you need to
preload them? What advantage does it get you?

Maybe there is another way to get what you are trying to accomplish.
Ccfe7d097475a32dc3ff78d6fc42c852?d=identicon&s=25 List Recv (lstrecv)
on 2005-12-12 03:32
nicholas.stuart wrote:
> Could you explain why you would want to do this? If the test fixtures
> get loaded automatically, as they do normally, why do you need to
> preload them? What advantage does it get you?
>
> Maybe there is another way to get what you are trying to accomplish.

Loading fixtures into the db for each test is sloooow.  I have a rake
script to preload them once.  Since each test runs under a transaction,
they leave the db just like they were beforehand.

So far, so good.

Buuut....

For my tests to work properly, they need to know what's in the yaml
fixture files.  They reference them using instance variables.  So, I'd
like to tell the test routines to load the fixtures into the instane
vars but NOT the db.
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2005-12-12 03:42
(Received via mailing list)
On 12/11/05, List Recv <listrecv@gmail.com> wrote:
>
> So far, so good.
>
> Buuut....
>
> For my tests to work properly, they need to know what's in the yaml
> fixture files.  They reference them using instance variables.  So, I'd
> like to tell the test routines to load the fixtures into the instane
> vars but NOT the db.

You just want objects that you can play around with then, but not have
them be records in your db?  If that's the case, why not just create
another ruby file that instantiates the objects you want, and then
include that file in the tests that need them?  I know it kinda sucks
and is not very DRY, but that's the best way I can think of it.

Maybe you could use eRB in your fixtures to be like "name = <%
@instance.name %>" kinda thing, and that way you have a fixtures file
that gets its info from the instances file.  Not sure if you can do
that, but it'd eliminate the duplication of instance data at least
(though you'd still have to duplicate attribute names).

Pat
This topic is locked and can not be replied to.