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:
- 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.
-
Generate a lot of fixtures somehow using some kind of system that
basically makes it easier to have a lot of associated models.
-
Something else i’m too ignorant to think of.
Does anyone have any advice/guidance/urls/etc regarding this?
thanks
max
Max W. 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.
[…]
- 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
[email protected]
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.
[…]
- 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:
That looks really useful as well, thanks WJ!
cheers
max
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?