On 16 Feb 2012, at 12:21, David Chelimsky wrote: > On Thu, Feb 16, 2012 at 4:17 AM, Matt Wynne <m...@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 <jko...@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 <jko...@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@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?
I know how you feel, but I will try to help, yes. I think reading the feature is a good place to start: that's where I dumped my understanding of the problem when I last worked on it: >> https://github.com/cucumber/cucumber-rails/blob/master/features/choose_javascript_database_strategy.feature cheers, Matt -- Freelance programmer & coach Author, http://pragprog.com/book/hwcuc/the-cucumber-book Founder, http://www.relishapp.com/ Twitter, https://twitter.com/mattwynne
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
