Forum: Ruby on Rails Selenium - tips for avoiding a hundred fixture files.

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.
73c04e9ef9ca435c5b19a2e765ae6d20?d=identicon&s=25 Max Williams (max-williams)
on 2009-05-13 15:23
I've just started using Selenium with Rspec and it's working well so
far.  However, i'm testing it against my local development version of
the site (ie running in mongrel).  What i really need to do is run it in
a test environment, so i can do destructive actions repeatedly.

Using fixtures seems like one obvious way to go - since it's a form of
integration testing i don't want to start mocking and stubbing things,
that's just going to cause more confusion and problems than it solves.
So, i could fixture everything up the wazoo.

The problem is, though, that we have a big site with loads of different
tables, and lots of different interrelated models.  Setting up all the
fixtures is going to be a pain in the ass.  So, i thought of a few ways
to go:

1) Make a stripped down version of our db, by basically deleting lots of
records and all their associations out.  Then

  a) Generate fixtures, or some data (maybe even just an sql file) that
is loaded into the db before every test.  This is going to be very slow
as the data will be reloaded *a lot*.

  b) Run every test (or group of tests) in a transaction, so the changes
are always undone after every test.  This should be a lot quicker than
1a.

2) Generate a lot of fixtures somehow using some kind of system that
basically makes it easier to have a lot of associated models.

3) Something else i'm too ignorant to think of.

Does anyone have any advice/guidance/urls/etc regarding this?

thanks
max
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-13 16:18
Max Williams wrote:
> I've just started using Selenium with Rspec and it's working well so
> far.  However, i'm testing it against my local development version of
> the site (ie running in mongrel).  What i really need to do is run it in
> a test environment, so i can do destructive actions repeatedly.

Investigate Webrat (and ots Selenium bindings if you need them).
Cucumber may also be nice here.

>
> Using fixtures seems like one obvious way to go

The obvious is not always the best. :)

[...]
>   a) Generate fixtures, or some data (maybe even just an sql file) that
> is loaded into the db before every test.  This is going to be very slow
> as the data will be reloaded *a lot*.

Remember, Rspec already clears the test database before each test.

What you have here is a good use case for factories, I think.  Install
Machinist or Factory Girl and just tell it what you need for each
particular test.  It will take care of the dependencies.
[...]
> 2) Generate a lot of fixtures somehow using some kind of system that
> basically makes it easier to have a lot of associated models.

This is sort of what factories do.  There's a Railscast on the subject.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
A66a4d323674aba4a904ceeff3f34658?d=identicon&s=25 WJSimacek (Guest)
on 2009-05-13 16:27
(Received via mailing list)
On May 13, 9:18 am, Marnen Laibow-Koser <rails-mailing-l...@andreas-
s.net> wrote:
>
> Remember, Rspec already clears the test database before each test.
>
> What you have here is a good use case for factories, I think.  Install
> Machinist or Factory Girl and just tell it what you need for each
> particular test.  It will take care of the dependencies.
> [...]
>
> > 2) Generate a lot of fixtures somehow using some kind of system that
> > basically makes it easier to have a lot of associated models.
>
> This is sort of what factories do.  There's a Railscast on the subject.

Check out this Railscast that uses two gems populator and faker to
create a rake that loads a database with fake data:

http://railscasts.com/episodes/126-populating-a-database
73c04e9ef9ca435c5b19a2e765ae6d20?d=identicon&s=25 Max Williams (max-williams)
on 2009-05-13 16:37
Thanks a lot Marnen.

Someone else has recommended machinist to me, and it gets a mention in
the screencast too.  I'll check it out.

Can you think of anything i need to bear in mind when doing integration
testing (well, acceptance testing really since it's simulating a user)
like selenium?

for example, are there any things that i should still mock out?  or is
it best to create a ton of real objects of every kind using the factory?
73c04e9ef9ca435c5b19a2e765ae6d20?d=identicon&s=25 Max Williams (max-williams)
on 2009-05-14 13:35
That looks really useful as well, thanks WJ!

cheers
max
This topic is locked and can not be replied to.