-
-
Save dhh/893027 to your computer and use it in GitHub Desktop.
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 |
@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.
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.
@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.