On Oct 24, 2007, at 2:58 AM, Scott Taylor wrote: Is no one else experiencing roll back problems on Trunk rspec?
Scott > > On Oct 23, 2007, at 1:54 PM, David Chelimsky wrote: > >> On 10/23/07, sinclair bain <[EMAIL PROTECTED]> wrote: >>> Oops, >>> >>> A bit over-zealous on the send. >>> >>> As I meant to add >>> This was not the case last week. This did not occur until >>> yesterday when I >>> svn upped the project (I had installed the rspec trunk as an >>> svn:external). >>> This all occurs on WindowsXP >> >> Ah - I am therefore not able to help debug this precisely - though I >> did follow your instructions and got a different error: >> >> 1) >> SQLite3::SQLException in 'trunk error should not fail' >> cannot start a transaction within a transaction >> /Users/david/projects/ruby/trunk-error/vendor/plugins/ >> rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in >> `before_eval' >> >> 2) >> SQLite3::SQLException in 'trunk error should fail' >> cannot start a transaction within a transaction >> /Users/david/projects/ruby/trunk-error/vendor/plugins/ >> rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in >> `before_eval' >> >> Setting config.use_transactional_fixtures = false in >> spec/spec_helper.rb resolved that. Any chance that is the source of >> your problem? > > My guess is that something screwy is going on with transactional > fixtures / rollbacks with rspec. (I'm running on rspec trunk, rails > 1.2.3) Two things tip me off to this: > > 1. I was able to use sqlite3 a few days ago. Now I'm getting a > series of errors if I try to run sqlite3 in test mode (as per the > original report). I haven't tried turning off transactional > fixtures, but when I do, I'll report back. > 2. My colleague/co-worker runs the test suite with rake spec, I > prefer to use Autotest. His tests have been passing, while when I > run them, they are failing. We have removed the fixtures directory > both from the test and spec directories. We generate the data per > test case (or in setup/before(:each) blocks). Here was one test, > which was failing (although passing two days ago): > > describe %(User who is trying to ignore items from the review > queue) do > > before :each do > @user = create_user > end > > it "should not find any of the ignored items in the review > queue" do > item = create_writing > create_ignored_item(:created_at => 25.hours.ago, :user => > @user, :item => item) > @user.hack_review_queue.should == [] > end > end > > Running ruby-debug, I found that in the example there were 80 Items > left hanging around. Only one Item should be around from this test > case. Adding the following did the trick: > > before(:each) do > Item.delete_all > @user = create_user > end > > (There is also one more example in this description block which > creates 20 items, which I've omitted for clarity. Sorry if the spec > is opaque - the method under question is looking for an Item which > isn't being ignored/skipped, and I've created just one item, which > *is* being skipped, so it shouldn't find that one item in our queue). > > The point of this is: 80 items shouldn't be hanging around. Looks > like a problem of transactional fixtures (which rolls back to the > test database for every test case). > > Scott > > > > > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
