In my previous posts on blogs and email lists, etc, I’ve talked about using setup as the context in which each spec is run. The problem that I’ve come to recognize is that there are often so many variables in contexts that things can quickly get quite confusing.

So rather than using setup as the context, I’ve begun to use setup to take care of what NEEDS to happen in order for the specs to be able to run, but have each specify block tell a complete story, including its own context (i.e. Givens).

To accomplish this, I like to stub methods in setup and reserve should_receive for expectations within the specs themselves. Of late, I’ve also been commenting the specs to clarify the Given/When/Then in each spec. Given/When/Then is conceptually the same as Build/Operate/Check, but with slightly different words chosen to be a little more customer friendly:

Given preconditions When action Then outcome

Mock expectations become part of the Givens. This takes a minute to get used to, but becomes quite natural.

The specs end up far more verbose, but they are VERY clear and more true to the BDD triad of Given/When/Then. Here’s the example with the triad commented. I’m curious to hear what you think about it:

context "Given a request to render message/list with one message the page" do
  setup do
    @message = mock "message" 
    @caller = mock "person",:null_object=>true
    @school = mock "school" 

    @message.stub!(:school).and_return(school)
    @message.stub!(:time).and_return(Time.parse("12/31/06"))
    @message.stub!(:caller).and_return(@caller)
    @message.stub!(:iep).and_return(true)

    @caller.stub!(:first_name).and_return("first")
    @caller.stub!(:last_name).and_return("second")

    @school.stub!(:name).and_return("school name")
    assigns[:messages]=[m]
    assigns[:message_pages] = mock "message_pages", :null_object=>true
  end

  specify "should show the time" do
    #given
    @message.should_receive(:time).and_return(Time.parse("1/5/07"))

    #when
    render 'message/list'

    #then    
    response.should_have_tag :td, :content=>"12:00 AM 1/5", :attributes=>{:id=>"time"}
  end

  specify "should show caller first and last name" do
    #given
    @caller. should_receive(:first_name).and_return("Bob")
    @caller. should_receive(:last_name).and_return("Martin")

    #when
    render 'message/list'

    #then
    response.should_have_tag :td, :content=>"Bob Martin", :attributes=>{:id=>"caller"}
  end

  specify "should show school name" do
    #given
    @school. should_receive(:name).and_return("Jefferson")

    #when
    render 'message/list'

    #then
    response.should_have_tag :td, :content=>"Jefferson", :attributes=>{:id=>"school"}
  end

  specify "should show X in the IEP field when IEP is true" do
    #given
    @message.should_receive(:iep).and_return(true)

    #when
    render 'message/list'

    #then
    response.should_have_tag :td, :content=>"X",:attributes=>{:id=>"iep"}
  end

  specify "should show nothing in the IEP field when IEP is false" do
    #given
    @message.should_receive(:iep).and_return(false)

    #when
    render 'message/list'

    #then
    response.should_have_tag :td, :content=>"",:attributes=>{:id=>"iep"}
  end
end

As I noted above, the specs become more verbose and even bear some duplication. As you may know, I have much less trouble with duplication in specs than I do with duplication in the code being specified.

Thoughts and comments are welcome.