On 9/4/07, <b class="gmail_sendername">Jay Levitt</b> <<a href="mailto:lists-rspec@shopwatch.org">lists-rspec@shopwatch.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Seems like, in this case, he'd output @person.errors in his message so<br>he could see *why* person was invalid; the "puts" is his current<br>hack-around for the lack of custom messages.<br><br>Not a bad idea, really. (the custom messages, not the hackaround!)
<br></blockquote></div><br>Yes, exactly; I often write the simple case with no extra message first, then the first time the failing unit test doesn't give me enough information to fix the problem, I add a custom message that makes it easier.
<br><br>Examples culled from Test::Unit code:<br><ul><li>assert_select "a[href*=#{rev_1_url}]", true, "could not find #{rev_1_url} in #{@response.body}"</li><ul><li>In this case, it failed to find the URL, but I wasn't sure why that would be; adding the response body made it possible for me to diagnose that the expected URL I'd generated didn't match because the ID was off. This kind of response is pretty spammy (entire response text), so I'd definitely only employ this if it was present only in the case of failure.
</li></ul><li>assert_response :ok, "Failed to restore contact_info: #{@response.body}"<br></li><ul><li>A similarly spammy @response.body output; wasn't sure why the response wasn't :ok, turned out to be a validation failure triggered by restoring a no-longer-valid revision.
</li></ul><li>assert customer.valid?, "Fixture customer is expected to be valid: #{customer.errors.full_messages.join(', ')}"</li><ul><li>Pretty similar to the example I used above; unexpected validation failure, it's nice to see the errors.
</li></ul></ul>Are any of these critical to RSpec's main goals? Probably not. Will it prevent my adopting RSpec? Probably not. Is it still handy to have so that you don't employ other means (e.g. commented out puts) for repeat diagnosis of failures? I think so.
<br><br>That said, if none of the above convinces you, then by all means, I'll go ahead with the standard RSpec approach and see if, in a few months, I'm still missing this feature and, if so, I'll have good RSpec examples in hand, with which to discuss. ;)
<br><br> - Geoffrey<br>--<br> Geoffrey Wiseman<br>