Prevent database rollback in specs in Ruby on Rails?

Question

When running RSpec tests in Ruby on Rails 2.3 with ActiveRecord, the database gets rolled back to the state after a before :all block after each example (it block).

However, I want to spec the lifecycle of an object, which means going through a number of examples one by one, changing the state and testing postconditions. This is impossible with the rollback behaviour.

So to clarify:

describe MyModel
  before :all { @thing = MyModel.create }

  it "should be settable" do
    lambda { @thing.a_number = 42 }.should_not raise_exception
  end

  it "should remember things" do
    @thing.a_number.should == 42
    # this fails because the database was rolled back ☹
  end
end

Is there some way to persist changes made in examples?

score 3 · Answer 1 · answered Sep 14 '11 at 13:21

I agree with normalocity, in this case it looks like you would be better off with a single spec containing two assertions.

There are cases in which it is helpful to turn off rollbacks, e.g. for higher level tests with Capybara and Selenium, in which case you can use the use_transactional_fixtures configuration option. You can put thi

RSpec.configure do |config|
  config.use_transactional_fixtures = false
end

score 0 · Answer 2 · answered Sep 14 '11 at 13:12

0

Well, that depends on what you're trying to do. If you're testing the life cycle (a series of things that happen over time), that's more the realm of integration tests, which you can build more in tools such as Cucumber, etc. Spec is more designed to do small tests of small bits of code.

It's technically possible for you to simply write a long spec test, with multiple .should statements, and so long as all of them pass, then you've effectively got the kind of test you're describing. However, that's not really, in my experience, what spec is designed to give you.

I guess what I'm saying is, don't try to prevent the rollback - that's not what it's there to do. Either use a tool more designed to do the kinds of tests you're looking to build, or write a longer test that has multiple .should statements.

answered Sep 14 '11 at 13:12

jefflunt

33,527
7
88
126

Hum, thanks I guess. TBH, I don't like Cucumber at all (it breaks the basic tenet that a DSL is ultimately still a programming language and should not attempt to look too "natural") and just want to avoid using it as far as possible. – Nicos Sep 14 '11 at 14:46
Yeah, I have similar issues with Cucumber, because regardless of how "natural" a language looks, computers are still too concrete in their interpretation to actually know what a user *means* outside of a very strict vocabulary (which you must, of course, define via step definitions). But, one of the goals of Cucumber is to also allow non-programmers to understand what a Cucumber test is doing, hence the choice to phrase them in terms of what the user experiences and does, rather than the underlying system that accomplishes them. – jefflunt Sep 14 '11 at 14:59
They said the same thing about COBOL, which was ultimately only usable by highly trained people. At this point I'm really doing "extended unit tests" and laying out atomic business logic, not integration, so the testing framework scope is ambiguous but highly slanted towards unit testing, so I'll rather work around the rollbacks at the cost of longer-running specs. – Nicos Sep 14 '11 at 15:04

Prevent database rollback in specs in Ruby on Rails?

2 Answers2