[rspec-users] Loading (or stubbing) data before model loading
dchelimsky at gmail.com
Wed Jul 22 09:44:22 EDT 2009
On Wed, Jul 22, 2009 at 8:27 AM, Tom Stuart<tom at experthuman.com> wrote:
> On 22 Jul 2009, at 13:57, David Chelimsky wrote:
>>> The problem is that RSpec starts with an empty test database
>> Not exactly. RSpec starts with whatever database you have and rolls
>> back to that state after each example provided you're only using
>> before(:each) to set up state before each example.
> Quite right, and I should've been more specific: rake spec sets up an empty
> database and then runs RSpec. In the end I solved my problem by extending
> the db:test:prepare task to load the fixtures after cloning the development
> database structure, which in hindsight is obviously the right way to fix it.
>> Any pre-existing database state will remain, and any state that you
>> set up in before(:suite) or before(:all) will not be rolled back
>> unless you do so explicitly.
> On an unrelated note, why do I occasionally see leakage of fixture data
> between specs? I'd expect RSpec's explicit state rollback
There is no such thing as RSpec's explicit state rollback, thought
that does sound quite fancy.
All RSpec does is create new instances of each example group to run
each example in. That means that any local state does not get copied
from one example to another. You are responsible for managing any
global state. The same is true for any other testing framework btw (at
least those that I know of).
> , plus Rails'
> transactional fixtures, to mean that fixtures loaded in one example would
> always be invisible to another, but that doesn't seem to be the case; I've
> seen many instances of mysteriously-appearing spec failures which turned out
> to be because of a change in running order (touching files + --loadby mtime
> --reverse) causing fixture leakage to move somewhere else, always easily
> remedied by explicitly loading whatever fixture had been forgotten. Is this
> a bug somewhere in RSpec or Rails (or MySQL), or something I'm just doing
I can't speak for your situation in specific, but here are some possible causes:
* setting up state in a before(:all)
This data is not rolled back after the example group is run, so you
have to explicitly roll it back in an after(:all). If other specs were
passing due to state set up in a before(:all) that wasn't properly
matched with an after(:all) cleanup and happened to run before those
passing specs, then running those specs in isolation, or before the
offending group (with the before(:all)) may cause them to fail.
* data-backed global variables
This may seem counter-intuitive, since the database is rolled back
after each example - but keep in mind that _only_ the database is
rollled back. If a data-backed model is loaded into memory in a global
variable, that object is still there, even if the record in the
database no longer exists.
More information about the rspec-users