[rspec-users] Question about structuring specs

Ijonas Kisselbach ijonas.kisselbach at gmail.com
Mon Jan 4 06:26:42 EST 2010

Hi David,

I see your point about concentrating on outcomes rather than implementation.
I suppose who cares about implementation, its the effect code on the "state
of the world" that is important.

Here's an unmodified sample:
  context ", when a new policy is activated on unchanged content" do
    before(:each) do

    it "should create a new policy, the new violation and location, resolve
previous violations, recalculate location MD5, and refresh caches" do
      # content hasn't changed
      @content = mock(:content, :content_md5 => "84290324908230948",
:most_recent_violations => [mock(:violation_mr, :update_folder_count =>
      @content_descriptor = mock(:content_descriptor, :contents =>
[@content], :most_recent_content => @content, :folder => mock(:folder))


      # Policy is new, gets created once


      # below are the changes affected


      violation = mock(:new_violation1, :location_md5= => nil, :save =>




I'm going to try and refactor the specs so that anything that doesn't
directly modify state of the app is removed.


On Mon, Jan 4, 2010 at 11:16 AM, David Chelimsky <dchelimsky at gmail.com>wrote:

> On Mon, Jan 4, 2010 at 4:33 AM, Ijonas Kisselbach <
> ijonas.kisselbach at gmail.com> wrote:
>> Hi,
>> 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
>> same"
>>    context ", when new policies are activated, but content remains the
>> same"
>> end
>> 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"
>> do
>>    it "should create the new policy" do
>>       # a whole bunch of expectations testing the policy creation part of
>> the process
>>    end
>>    it "should create a new violation and location" do
>>      # a whole bunch of expectations testing the violation creation part
>> of the process
>>    end
>>    it "should resolve previous violations" do
>>      # a whole bunch of expections testing retrieval of previous
>> violations and performing updates on them
>>    end
>>   ....
>> end
>> 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
> "Policy.find(@policy_id).should_not be_nil"?
> David
>> (I'm using rspec 1.2.9 and Rails 2.2.2 on OSX)
>> Regards,
>> Ijonas.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20100104/b87d80b3/attachment.html>

More information about the rspec-users mailing list