On Jun 18, 11:02 am, Peter van Hardenberg <[email protected]> wrote:
> Transactions seem like an interesting approach, but they don't protect you
> from your tests assuming some kind of existing state.
In most of my apps, the initial state when testing is assumed to be
the result of running the migrations and nothing else (i.e. current
schema and empty database tables).
> Wouldn't that approach
> also require your tests to run within the scope of a single database
> connection?
Depends. If you have multiple static database connections, it's easy
to have a transaction open on each. However, if you have actions that
create their own connections (threading/sharding), then such an
approach either won't work or will take additional setup.
> 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
No. Then Sequel doesn't know you are already in a transaction, and
will attempt to create new transactions. Francois's example is the
recommended way.
> Creating the database via migrations with each test run also helps guarantee
> that your migrations result in at least a reasonable schema.
You could start with a completely empty database (no tables), and do a
full upward migration before every spec (inside a transaction), but
that's going to be slower, will require transactional schema
modification, and I can't see the benefit.
I think migrating your test database outside of the specs works best,
and it's very similar to how I migrate my development and production
databases.
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].
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.
