Cucumber/Webrat fails to find fields when run after specs

I’ve been battling the strangest behavior, and hoping someone can shed
some
light…
I am using RSpec for MVC tests, and then Cucumber for stories/features.
I
am new to Cucumber, and recently finished converting our RSpec Story
Runner
suite to it. What I’m seeing is that if I clean the database (e.g. rake
db:reset), then run all my specs, then run the features, Webrat fails to
find various fields on form pages. If I run them in the reverse order,
with
features first, then specs, often times various specs fail (seems
somewhat
random and odd in what may fail).

I believe that if I clean the database between each, that things work.
I
did not previously have to do that with story runner. But, also, what
I’m
finding is that I can’t seem to run rake db:reset twice in the same rake
task (due to Rake’s usual not allowing that), so this makes setting up a
rake task for CruiseControl.rb hard, as it won’t reset the DB a second
time.
I could probably just run it as a shell command, but that seems like a
terrible hack.

I’m running into this both on MacOS X, and on my CI server which is
Ubuntu
8.04 running CruiseControl.rb (from git://
GitHub - benburkert/cruisecontrolrb: CruiseControl.rb is a continuous integration tool, written in Ruby. It is quick to install, simple to use and easy to hack.). Has anyone else seen this
kind
of thing, any ideas? My versions:

ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]
rails (2.2.2)
rspec (1.1.11)
rspec-rails (1.1.11)
aslakhellesoy-cucumber (0.1.99.19)
nokogiri (1.1.1)
webrat (0.4.1)

On Wed, Feb 4, 2009 at 7:21 PM, Christopher B.
[email protected] wrote:

I’ve been battling the strangest behavior, and hoping someone can shed some
light…
I am using RSpec for MVC tests, and then Cucumber for stories/features. I
am new to Cucumber, and recently finished converting our RSpec Story Runner
suite to it. What I’m seeing is that if I clean the database (e.g. rake
db:reset), then run all my specs, then run the features, Webrat fails to
find various fields on form pages. If I run them in the reverse order, with

Use puts response.body in the failing step definitions to see the html

features first, then specs, often times various specs fail (seems somewhat
random and odd in what may fail).

Sounds like you have residual data in your test database. Do you have
transactions turned on for both rspec and cucumber?
Do your features rely on specific data being in the database before
the run? How do you get it in there?

Aslak

On Wed, Feb 4, 2009 at 12:54 PM, aslak hellesoy
[email protected]wrote:

db:reset), then run all my specs, then run the features, Webrat fails to
find various fields on form pages. If I run them in the reverse order,
with

Use puts response.body in the failing step definitions to see the html

I’ll do that (can’t at the moment, but will next go-around).

features first, then specs, often times various specs fail (seems
somewhat
random and odd in what may fail).

Sounds like you have residual data in your test database. Do you have
transactions turned on for both rspec and cucumber?
Do your features rely on specific data being in the database before
the run? How do you get it in there?

I start with a clean DB, then run the specs. At the end, data is left
in
there. I am running transactional RSpec specs as far as I know,
although
maybe there’s something explicit I need to do? I thought they were on
by
default. I’ve noticed that data gets leftover between tests a lot. I
see
that I have transactional fixtures enabled (I don’t use any fixtures
though

  • all my data is created by my own factory methods/generators which are
    either run in before methods or in the actual spec case). I have
    Cucumber
    transactional turned on via this line in env.rb:

Cucumber::Rails.use_transactional_fixtures

No features rely on any pre-existing data.

Just normal Webrat, no Selenium, it’s not installed, etc.
I’ve now got things working, although I honestly have no idea what
changed
that makes it consistently run now. I did update to rspec and
rspec-rails
1.1.12, but it still failed for a while after that.

My primary residual concern is that the DB isn’t clean after the specs
run,
which means it’s not clean for the features/Cucumber run. I can’t seem
to
get db:reset rake task to run again because rake has already run it (and
calling reenable on it doesn’t seem to change that). I’ve tried a few
alternatives to calling that task specifically, but I think rake has
seen
them all as dependencies or what not already.

Are you running selenium or normal webrat (eg config.mode = :rails or
config.mode = :selenium)?

On Wed, Feb 4, 2009 at 11:08 PM, Christopher B.
[email protected]wrote:

My primary residual concern is that the DB isn’t clean after the specs run,
which means it’s not clean for the features/Cucumber run.

Fixtures?

///ark

On Thu, Feb 5, 2009 at 1:43 AM, Christopher B.
[email protected] wrote:

am new to Cucumber, and recently finished converting our RSpec Story

features first, then specs, often times various specs fail (seems
somewhat
random and odd in what may fail).

Sounds like you have residual data in your test database. Do you have
transactions turned on for both rspec and cucumber?
Do your features rely on specific data being in the database before
the run? How do you get it in there?

I start with a clean DB, then run the specs. At the end, data is left in

That’s probably the source of your problem. Either fix it so that data
in DB after specs == data before. Or if you can’t do that - clear the
db before running cucumber.
You can invoke a Rake task explicitly with something like
Task[‘taskname’].invoke

Aslak

I don’t use fixtures or have any anywhere.

Data before is nothing. I’m not sure why there’s data after.
I would clear the data before running Cucumber, but after running specs
by
doing a “rake db:reset” or similar, but it has no effect, because that’s
the
same task that started off the whole thing. I’m running this under
CruiseControl and so you set up a cruise task, which looks like:

task :cruise do
RAILS_ENV = ENV[‘RAILS_ENV’] = ‘test’
CruiseControl::invoke_rake_task ‘db:reset’
CruiseControl::invoke_rake_task ‘cruise_coverage’
CruiseControl::invoke_rake_task ‘db:reset’ # This one has no effect
CruiseControl::invoke_rake_task ‘features’
CruiseControl::invoke_rake_task ‘ci_tag’
end

I’ve marked it as you can see, where that second db:reset has no effect
(because Rake thinks it has already run it (which it has) above). I’ve
tried doing things like making the “features” rake task itself depend on
db:reset, or depend on a custom task that does a db:reset, etc., but
while
you see CruiseControl spit out that it’s supposed to do that task, the
task
never gets run. This is the same behavior if you do it simply with
something like:

task :twotest do
Rake::Task[‘db:reset’].invoke
puts “do it again…”
Rake::Task[‘db:reset’].reenable # this doesn’t appear to work
Rake::Task[‘db:reset’].invoke
end

That will only run it once. I can resort to doing a shell command, but
what
a hack, seems like there has to be better way.