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.helle...@gmail.com <mailto:aslak.helle...@gmail.com>> wrote:
On Wed, Feb 4, 2009 at 7:21 PM, Christopher Bailey
<ch...@cobaltedge.com <mailto:ch...@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@rubyforge.org <mailto:rspec-users@rubyforge.org>
> http://rubyforge.org/mailman/listinfo/rspec-users
>
--
Aslak (::)
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org <mailto:rspec-users@rubyforge.org>
http://rubyforge.org/mailman/listinfo/rspec-users
--
Christopher Bailey
Cobalt Edge LLC
http://cobaltedge.com
------------------------------------------------------------------------
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
