Forum: RSpec Cucumber/Webrat fails to find fields when run after specs

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.
F76a533f96ab5281b996e3df79aa9832?d=identicon&s=25 Christopher Bailey (Guest)
on 2009-02-04 19:32
(Received via mailing list)
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.com/benburkert/cruisecontrolrb.git).  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)
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (aslakhellesoy)
on 2009-02-04 21:59
(Received via mailing list)
On Wed, Feb 4, 2009 at 7:21 PM, Christopher Bailey
<chris@cobaltedge.com> 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
F76a533f96ab5281b996e3df79aa9832?d=identicon&s=25 Christopher Bailey (Guest)
on 2009-02-05 02:16
(Received via mailing list)
On Wed, Feb 4, 2009 at 12:54 PM, aslak hellesoy
<aslak.hellesoy@gmail.com>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.
314c6f48cee7a540473e6ff0178a78eb?d=identicon&s=25 Mike Gaffney (Guest)
on 2009-02-05 07:06
(Received via mailing list)
Are you running selenium or normal webrat (eg config.mode = :rails or
config.mode = :selenium)?
F76a533f96ab5281b996e3df79aa9832?d=identicon&s=25 Christopher Bailey (Guest)
on 2009-02-05 08:30
(Received via mailing list)
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.
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2009-02-05 08:48
(Received via mailing list)
On Wed, Feb 4, 2009 at 11:08 PM, Christopher Bailey
<chris@cobaltedge.com>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
F76a533f96ab5281b996e3df79aa9832?d=identicon&s=25 Christopher Bailey (Guest)
on 2009-02-05 09:25
(Received via mailing list)
I don't use fixtures or have any anywhere.
0be0e4aa42aacd9a8a95c792de273ca7?d=identicon&s=25 Aslak Hellesøy (aslakhellesoy)
on 2009-02-05 11:00
(Received via mailing list)
On Thu, Feb 5, 2009 at 1:43 AM, Christopher Bailey
<chris@cobaltedge.com> 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
F76a533f96ab5281b996e3df79aa9832?d=identicon&s=25 Christopher Bailey (Guest)
on 2009-02-05 11:40
(Received via mailing list)
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.
This topic is locked and can not be replied to.