Rails - May 2009 - Selenium - tips for avoiding a hundred fixture files.

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
-- 
Posted via http://www.ruby-forum.com/.

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

On May 13, 9:18 am, Marnen Laibow-Koser <rails-mailing-l...@andreas-
s.net> wrote:
> 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.
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

>
> Best,
> --
> Marnen Laibow-Koserhttp://www.marnen.org
> mar...-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
> --
> Posted viahttp://www.ruby-forum.com/.

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?
-- 
Posted via http://www.ruby-forum.com/.

That looks really useful as well, thanks WJ!

cheers
max
-- 
Posted via http://www.ruby-forum.com/.