[rspec-users] Cucumber/Webrat fails to find fields when run after specs

Christopher Bailey chris at cobaltedge.com
Thu Feb 5 02:08:14 EST 2009


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.

On Wed, Feb 4, 2009 at 9:47 PM, Mike Gaffney <mr.gaffo at gmail.com> wrote:

> Are you running selenium or normal webrat (eg config.mode = :rails or
> config.mode = :selenium)?
>
>
> Christopher Bailey wrote:
>
>> On Wed, Feb 4, 2009 at 12:54 PM, aslak hellesoy <aslak.hellesoy at gmail.com<mailto:
>> aslak.hellesoy at gmail.com>> wrote:
>>
>>    On Wed, Feb 4, 2009 at 7:21 PM, Christopher Bailey
>>    <chris at cobaltedge.com <mailto:chris at 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
>>
>>
>> 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.
>>
>>
>>    Aslak
>>
>>    > 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
>>    <http://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)
>>    > --
>>    > Christopher Bailey
>>    > Cobalt Edge LLC
>>    > http://cobaltedge.com
>>    >
>>    > _______________________________________________
>>    > rspec-users mailing list
>>    > rspec-users at rubyforge.org <mailto:rspec-users at rubyforge.org>
>>    > http://rubyforge.org/mailman/listinfo/rspec-users
>>    >
>>
>>
>>
>>    --
>>    Aslak (::)
>>    _______________________________________________
>>    rspec-users mailing list
>>    rspec-users at rubyforge.org <mailto:rspec-users at rubyforge.org>
>>    http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>
>>
>>
>> --
>> Christopher Bailey
>> Cobalt Edge LLC
>> http://cobaltedge.com
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>



-- 
Christopher Bailey
Cobalt Edge LLC
http://cobaltedge.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090204/6fe1a38c/attachment-0001.html>


More information about the rspec-users mailing list