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. On Thu, Feb 5, 2009 at 1:23 AM, aslak hellesoy <aslak.helle...@gmail.com>wrote: > On Thu, Feb 5, 2009 at 1:43 AM, Christopher Bailey <ch...@cobaltedge.com> > wrote: > > On Wed, Feb 4, 2009 at 12:54 PM, aslak hellesoy < > aslak.helle...@gmail.com> > > wrote: > >> > >> On Wed, Feb 4, 2009 at 7:21 PM, Christopher Bailey < > 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 > > 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 > > > 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). 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 > >> > http://rubyforge.org/mailman/listinfo/rspec-users > >> > > >> > >> > >> > >> -- > >> Aslak (::) > >> _______________________________________________ > >> rspec-users mailing list > >> 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 > > > > > > -- > Aslak (::) > _______________________________________________ > rspec-users mailing list > 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
