I use an #around block: RSpec.configure do |config| config.around(:each) do |example| DB.transaction do example.call end end end
Hope that helps! -- François Beausoleil http://github.com/francois Le samedi 18 juin 2011 à 14:02, Peter van Hardenberg a écrit : > Transactions seem like an interesting approach, but they don't protect you > from your tests assuming some kind of existing state. Wouldn't that approach > also require your tests to run within the scope of a single database > connection? That's probably alright for most use cases. Would you do > something like this? > > RSpec.configure do |config| > config.before(:each) do > Sequel::Model.db.execute("BEGIN") > end > config.after(:each) do > Sequel::Model.db.execute("ROLLBACK") > end > end > > Creating the database via migrations with each test run also helps guarantee > that your migrations result in at least a reasonable schema. > > -p > > On Sat, Jun 18, 2011 at 10:55 AM, Jeremy Evans <[email protected] > (mailto:[email protected])> wrote: > > On Jun 18, 9:44 am, Peter van Hardenberg <[email protected] (mailto:[email protected])> > > wrote: > > > > Well, I was trying to go for a nice atomicity in the tests (like some > > > > kind > > > > of database-testing Nirvana!), and the in-memory database might be fast > > > > enough to allow it, but I'll probably end up with a mix. > > > > > > Stick with the real thing. It's worth it. Here's a snippet that clears > > > your > > > DB before each test. > > > > > > RSpec.configure do |config| > > > config.before(:each) do > > > db = Sequel::Model.db > > > db.tables.each do |table| > > > db[table].delete > > > end > > > end > > > end > > > > I prefer the alternate approach where you run all of your specs inside > > transactions. That's fairly easy to do in RSpec2 using an around > > filter. > > > > One of the issues with that snippet is that it doesn't handle foreign > > key constraints, so if a later table has foreign keys referencing a > > previous table, you will likely get an error. In most cases (though > > not all), you can work around that by specifying the order of the > > tables, but using transactions would still be my recommendation for > > most code. The main reason to delete instead of using transactions is > > if the database access is done outside of the process (e.g. > > integration testing against a separately running webserver). > > > > Jeremy > > > > -- > > You received this message because you are subscribed to the Google Groups > > "sequel-talk" group. > > To post to this group, send email to [email protected] > > (mailto:[email protected]). > > To unsubscribe from this group, send email to > > [email protected] > > (mailto:sequel-talk%[email protected] > > (mailto:[email protected])). > > For more options, visit this group at > > http://groups.google.com/group/sequel-talk?hl=en. > > > > -- > Peter van Hardenberg > San Francisco, California > "Everything was beautiful, and nothing hurt." -- Kurt Vonnegut > -- > You received this message because you are subscribed to the Google Groups > "sequel-talk" group. > To post to this group, send email to [email protected] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[email protected]). > For more options, visit this group at > http://groups.google.com/group/sequel-talk?hl=en. -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
