Run cucumber on a different DB than test?

Testing RSpec
1

Hi all:

Is it possible to run Rails Cucumber spec in a different DB than the
test DB? I’d like to run the rspec and cucumber tests in parallel in my
cc.rb build, and as it is now, I get MYSQL deadlocks on occasion. I
could serialize them, but I’d like the quicker feedback of running them
in parallel.

Forrest

2

On Feb 26, 2009, at 1:19 PM, Forrest C. wrote:

Hi all:

Is it possible to run Rails Cucumber spec in a different DB than the
test DB? I’d like to run the rspec and cucumber tests in parallel
in my cc.rb build, and as it is now, I get MYSQL deadlocks on
occasion. I could serialize them, but I’d like the quicker feedback
of running them in parallel.

Why not create a new environment, and set RAILS_ENV=“test_cucumber” ?

Scott

3

On 26 Feb 2009, at 18:27, Scott T. wrote:

Why not create a new environment, and set RAILS_ENV=“test_cucumber” ?

Scott

We do this, and it’s entirely possible, in fact I highly recommend it.
We call our environment ‘features’

One gotcha is that rspec-rails and a certain file in rails[1] (which
cucumber requires into Cucumber::Rails::World) will stomp all over
your RAILS_ENV and set it back to ‘test’, which means that if you do
(and you really shouldn’t) have any code that depends on this being
set correctly, it will break.

I think rspec-rails is now fixed, though you might need to use David’s
latest version from github.

Please let me know how you get on running them in parallel for CI, as
I’d also like to do this. At the moment we just use the two
environments for faster feedback when we’re regressions testing
locally. How are you thinking about collecting the results, for
example? Piping them to separate files?

Matt W.
http://blog.mattwynne.net

[1]rails/railties/lib/test_help.rb at 77b0994c7835610982d708ce7ce5cd95e6e99e5a · rails/rails · GitHub

4

On Feb 27, 2009, at 11:41 AM, Matt W. wrote:

parallel in my cc.rb build, and as it is now, I get MYSQL

One gotcha is that rspec-rails and a certain file in rails[1] (which
cucumber requires into Cucumber::Rails::World) will stomp all over
your RAILS_ENV and set it back to ‘test’, which means that if you do
(and you really shouldn’t) have any code that depends on this being
set correctly, it will break.

Yeah, and certain rake tasks won’t work, if I recall properly.
RAILS_ENV=another_env rake db:test:prepare still reset the test
database, not the db in another_env.

Scott

5

On 27 Feb 2009, at 16:54, Scott T. wrote:

Yeah, and certain rake tasks won’t work, if I recall properly.
RAILS_ENV=another_env rake db:test:prepare still reset the test
database, not the db in another_env.

Scott

Indeed. I do have a fully-functioning rake db:features:prepare task
which I can share if anyone’s interested.

It’s kind of a shame - this aspect of Rails is not nearly so
extensible as it looks. I really should spend some effort pushing them
some patches instead of just bodging it in our codebase.

Matt W.
http://blog.mattwynne.net

6

Hi Matt:

Yeah, and certain rake tasks won’t work, if I recall properly.
RAILS_ENV=another_env rake db:test:prepare still reset the test
database, not the db in another_env.

Scott

Indeed. I do have a fully-functioning rake db:features:prepare task
which I can share if anyone’s interested.

I ran into this very same issue that Scott points out and you have
apparently solved, so I’m definitely interested.

So with this setup you can do a ‘rake spec’ and have it run on the test
DB, and ‘rake features’ and have it run on the features DB?

Forrest

7

On Feb 27, 2009, at 12:01 PM, Matt W. wrote:

On Feb 26, 2009, at 1:19 PM, Forrest C. wrote:
RAILS_ENV=“test_cucumber” ?
that if you do (and you really shouldn’t) have any code that

It’s kind of a shame - this aspect of Rails is not nearly so
extensible as it looks. I really should spend some effort pushing
them some patches instead of just bodging it in our codebase.

Of course one of the issues is that they do want to provide checks
for certain tasks.

You’d probably want an error RAILS_ENV=development rake db:test:prepare

Scott

8

On 27 Feb 2009, at 19:56, Forrest C. wrote:

I have 2 projects in cc.rb. Each is the same codebase but runs a
different target, so when a git change is pushed, they both kick off
in parallel.

Of course! I’ve been meaning to do this for ages, with a third build
that does the both sets of tests and then deploys to the demo
environment.

I also did something which you might be interested in with our build
to dynamically build a new database for the tests / features to run
in. Looking back I can’t actually see a why I did this, and you might
not need it. I think at the time I suspected that cruise was building
the same project multiple times in parallel if a second commit came in
while a build was already happening. I’m not sure if that’s actually
the case right now.

FWIW, here’s our cruise rake task. It uses an erb template for
database.yml which you’ll see from looking at the code.

Matt W.
http://blog.mattwynne.net

9

----- Original Message ----

Date: Fri, 27 Feb 2009 16:41:53 +0000
From: Matt W.

Please let me know how you get on running them in parallel for CI, as
I’d also like to do this. At the moment we just use the two
environments for faster feedback when we’re regressions testing
locally. How are you thinking about collecting the results, for
example? Piping them to separate files?

I have 2 projects in cc.rb. Each is the same codebase but runs a
different target, so when a git change is pushed, they both kick off in
parallel.

I was going to put html output into the custom build artifacts, and
possibly making a 3rd page to put all the results on one page.

Forrest

10

On 27 Feb 2009, at 19:59, Forrest C. wrote:

which I can share if anyone’s interested.

I ran into this very same issue that Scott points out and you have
apparently solved, so I’m definitely interested.

voila: rake_db_features_prepare.rb · GitHub

So with this setup you can do a ‘rake spec’ and have it run on the
test DB, and ‘rake features’ and have it run on the features DB?

Exactly. I usually have a couple of tabs open in the terminal and run
one in each.