[rspec-users] stale records with integration testing?

David Chelimsky dchelimsky at gmail.com
Thu Feb 16 07:21:58 EST 2012


On Thu, Feb 16, 2012 at 4:17 AM, Matt Wynne <matt at mattwynne.net> wrote:
>
> On 14 Feb 2012, at 20:44, Justin Ko wrote:
>
>
> 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.
>
>
> Probably because it's crazy complicated.

Seems so, but worthwhile. Also, I wasn't aware of the shared
connection strategy before this thread.

> If you do want to support it too,
> let's work out a way to factor it out into a single shared library.

I like this idea but am seriously overcommitted right now. Can you two
coordinate on this?

> FYI the
> feature for it is here:
> https://github.com/cucumber/cucumber-rails/blob/master/features/choose_javascript_database_strategy.feature
>
> cheers,
> Matt


More information about the rspec-users mailing list