Forum: RSpec Run cucumber on a different DB than test?

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.
Forrest C. (Guest)
on 2009-02-26 20:26
(Received via mailing list)
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
Scott T. (Guest)
on 2009-02-26 20:29
(Received via mailing list)
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
Matt W. (Guest)
on 2009-02-27 18:49
(Received via mailing list)
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
http://www.songkick.com

[1]http://github.com/rails/rails/blob/77b0994c7835610...
Scott T. (Guest)
on 2009-02-27 18:56
(Received via mailing list)
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
Matt W. (Guest)
on 2009-02-27 19:02
(Received via mailing list)
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
http://www.songkick.com
Scott T. (Guest)
on 2009-02-27 19:29
(Received via mailing list)
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
Forrest C. (Guest)
on 2009-02-28 15:04
(Received via mailing list)
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
Forrest C. (Guest)
on 2009-02-28 15:23
(Received via mailing list)
----- 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
Matt W. (Guest)
on 2009-02-28 15:31
(Received via mailing list)
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.

http://gist.github.com/71920


Matt W.
http://blog.mattwynne.net
http://www.songkick.com
Matt W. (Guest)
on 2009-02-28 15:48
(Received via mailing list)
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: http://gist.github.com/71918

> 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.
This topic is locked and can not be replied to.