[rspec-users] stale records with integration testing?

Justin Ko jko170 at gmail.com
Tue Feb 14 15:44:02 EST 2012


On Feb 14, 2012, at 9:23 AM, David Chelimsky wrote:

> On Tue, Feb 14, 2012 at 9:28 AM, Justin Ko <jko170 at gmail.com> wrote:
>> 
>> On Feb 13, 2012, at 10:35 PM, David Chelimsky wrote:
>> 
>>> On Mon, Feb 13, 2012 at 9:04 PM, Justin Ko <jko170 at gmail.com> wrote:
>>>> 
>>>> On Feb 13, 2012, at 1:16 PM, Patrick J. Collins wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I was writing an integration test for my user signup form (with
>>>>> capybara), and found that my test was failing due to a validation error:
>>>>> "email is already taken".  I'm a bit confused because I thought when I
>>>>> run "rspec spec/some_spec.rb", the test database would be wiped clear?
>>>>> 
>>>>> Is that not the case?
>>>>> 
>>>>> Patrick J. Collins
>>>>> http://collinatorstudios.com
>>>>> 
>>>>> _______________________________________________
>>>>> rspec-users mailing list
>>>>> rspec-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>> 
>>>> You basically have two options to ensure a clean database:
>>>> 
>>>> 1.) Transactional examples:
>>>> 
>>>> RSpec.configuration.use_transactional_examples = true
>>>> 
>>>> 2.) DatabaseCleaner:
>>>> 
>>>> RSpec.configure do |config|
>>>>  config.before { DatabaseCleaner.start }
>>>>  config.after { DatabaseCleaner.clean }
>>>> end
>>>> 
>>>> Look into what those do. Let us know if you get stuck.
>>> 
>>> What Justin says is true if you're running in the same process. If
>>> you're using Capybara to run examples in-bro.wser, then option 2 will
>>> work for you, but option 1 will not.
>> 
>> You can still do this with an AR patch. Look at the "Transactions and database setup" in the Capybara README.
> 
> "This may have thread safety implications and could cause strange
> failures, so use caution with this approach."
> 
>> Using DatabaseCleaner with truncation is SLOW.
> 
> True, but you can minimize that by using transaction by default, and
> specifying truncation for in-browser scenarios (which are already far
> slower than will be impacted by truncation).

cucumber-rails has good examples on how to set this up in RSpec:
https://github.com/cucumber/cucumber-rails/blob/master/lib/cucumber/rails/database.rb

It includes AR shared connection and truncation strategies. 

David, how come rspec-rails doesn't include support for these things as well? I don't really mind setting it up manually, but it does seem to be a necessary pattern for request specs.

> 
>> 
>>> _______________________________________________
>>> 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
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users



More information about the rspec-users mailing list