gistfile1.rb

describe "GET current" do
    before do
      @request.cookies['hidden_notices'] = "1,#{notices(:permanent).id}"
      get :current, :format => 'js'
    end

    it { should respond_with(:success) }
    it { should set_cookie(:hidden_notices).to("#{notices(:permanent).id}") }
    it { should render_template('notices/current') }
  end
end

# vs

test "GET current (or preferably an explanation WHY we are testing it)" do
  @request.cookies['hidden_notices'] = "1,#{notices(:permanent).id}"
  get :current, :format => 'js'

  assert          respond_with(:success)
  assert_equal    "#{notices(:permanent).id}", cookies[:hidden_notices]
  assert_template 'notices/current'
end

rspec has more lolcats, surely that is worth some points?

As a newcomer to ruby/rails testing, I found Test:Unit much easier to get started with. Switched to rspec recently when was asked to, and have a feeling it fits more smoothly into the BDD workflow. Still, Test::Unit is surely not un-cool!

Why have controller specs/tests? Testing on Rack is so much cleaner and easier to maintain.
I (nor the user) don't care what template got rendered, I just care what content got rendered.

Here's how I would really want to test this:

describe "GET /notices/current" do
  it "removes the prefix from the hidden_notices cookie and renders the current notices" do
    request.cookies['hidden_notices'] = "1,#{notices(:permanent).id}"
    get "/notices/current", {}, {"HTTP_ACCEPT" => "text/javascript"}

    response.code.should == 200
    cookies[:hidden_notices].should == "#{notices(:permanent).id}"
    response.body.should include("something I actually care about")
  end    
end

On Apr 1, 2011, at 4:05 AM, ***@***.*** wrote: I (nor the user) don't care what template got rendered, I just care what content got rendered.

Content tests can be extremely brittle. Sometimes you just want to make sure the correct template gets rendered in the right context. Admins should see admin content, and so forth... Different requirements and situations call for different spe/sts...

@btakita - "removes the prefix from the hidden_notices cookie and renders the current notices" <<- Isn't that a little much to digest? What if you needed to add another "should" in the example? The example description would get even more out of control.

IMO, one expectation per example really keeps things maintainable.

@xmlblog - Sometimes "brittle" tests are ok and part of the normal development feedback loop. A lot of the time the content rarely changes so it's not brittle anyways. If it is brittle, then the test can change. I guess it can be annoying at times, but whatevs.
Sure I can accept that you want to know what template gets rendered. I actually like the convention where templates render a div with a custom html attribute which contains the template path. It's easy to tell what templates are rendered when viewing the page in the browser.

@justinko - Yeah, there's multiple pieces of behavior there. Splitting things up works out well in certain situations. Sometimes it's easier just to have it all in one spec. Of course personal taste plays into this.

Just read the two versions out loud, they speak for themselves. See also rspec foo.rb -f s

I'm surprised you don't get it, @dhh, you've always been a wonderfully big advocate of communicative code.

@mattwynne: if when confronted with differing opinions you assume the other party simply doesn't "get it" you prevent yourself from useful communication entirely.

Also, the read out loud thing makes a lot of implicit assumptions not related to "communicative code." Communicative code does not automatically mean that when it's spoken it will communicate well. It usually means when it's read it will communicate well. Punctuation in code is not easily read, which is one of many reasons why code is usually read, not spoken. While it is certainly possible to write code that is fluidly spoken, this is not any sort of requirement of clear code. Indeed in Ruby there is lots of punctuation!

oh_noes! unless @ruby.has_punctuation?

@rubypanther you're right, it was off-hand of me to say "get it". What I meant was "appreciate why people find this a useful technique". RSpec isn't The Silver Bullet, but if it's working for a significant number of people, I think it's healthy for us to be curious about why that's the case.

Personally, I really find that whether I'm reading code out loud or in my head, the closer it is to the way I'd describe the behaviour in English, the less likely I am to miss a mistake.

@mattwaynne: I don't think it's a matter of word choice at all. You're still replacing his opinion with lack of knowledge.

He's been quite clear about it. In fact, that's largely his point: it's heavily used because of a cargo cult. The question you'd have him ask is exactly the question to which his answer brought us all here.

@jrwest there is no need for the r variable.

describe "GET current" do
  it "does the same thing as your example" do
    @request.cookies['hidden_notices'] = "1,#{notices(:permanent).id}"
    get :current, :format => 'js'

    response.should respond_with(:success) }
    response.should set_cookie(:hidden_notices).to("#{notices(:permanent).id}") }
    response.should render_template('notices/current') }
  end
end

But in the end still it comes down to taste.

@StevenGerrard

You have great code ... I love it

Thanks bro!

I can't take a design opinion seriously from the person who built rails.

Plus all the things that other people have pointed out about these examples being no way near equivalent.