[rspec-users] Question about structuring specs
dchelimsky at gmail.com
Mon Jan 4 06:16:14 EST 2010
On Mon, Jan 4, 2010 at 4:33 AM, Ijonas Kisselbach <
ijonas.kisselbach at gmail.com> wrote:
> I'm struggling with structuring my specs describing a large process in my
> app. There are multiple paths of execution through that process each of
> which I'm trying to describe using a different rspec context, eg.
> describe Violation do
> context ", when nothing has changed since the last run"
> context ", when new content has been created, but policies remain the
> context ", when new policies are activated, but content remains the
> Each of the three scenarios/context above have got a bunch of "it
> should..." blocks in it which in turn contain a whole bunch of
> should_receives and should_not_receives on various mocked objects, thereby
> exercising the functionality of the large process.
> I would like the context to read as follows:
> context ", when new policies are activated, but content remains the same"
> it "should create the new policy" do
> # a whole bunch of expectations testing the policy creation part of
> the process
> it "should create a new violation and location" do
> # a whole bunch of expectations testing the violation creation part of
> the process
> it "should resolve previous violations" do
> # a whole bunch of expections testing retrieval of previous violations
> and performing updates on them
> The problem is: if I compartmentalize my expectations into the individual
> it-should-blocks then something will fail in the execution of the large
> process, typically caused by a mock not being setup. If I lump all my
> expectations in the before(:each)-block then the whole thing springs to
> life, but I lose my compartmentalization of the specs and the whole thing
> becomes unreadable.
> I guess I'm looking for help and advice on how best combat the lumping of
> expectations into the before-block. Should I separate my stubbing from my
> expectations ?
> Many thanks for your advice.
I'd need to see the actual code to respond in any precise way here, but
generally, it sounds like you're specifying too much about the
implementation rather than the outcomes. What happens if you eliminate all
of the mocks in these examples and just have expectations like
> (I'm using rspec 1.2.9 and Rails 2.2.2 on OSX)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users