Pat Maddox wrote:
> On 9/4/07, David Chelimsky <[EMAIL PROTECTED]> wrote:
>
>> On 9/4/07, Geoffrey Wiseman <[EMAIL PROTECTED]> wrote:
>>
>>>> I come from the same background as you, so I hear where you're coming
>>>> from. We made a conscious decision, however, not to support custom
>>>> messages almost two years ago and I'm not sure if its ever even come
>>>> up before. If it has, it was a long time ago.
>>>>
>>> [nod] Perhaps as I get into the mindset, I'll find this desire slips away.
>>>
>>>
>>>> If you follow the conventions of one expectation per example, and your
>>>> example is well named, this is less of a problem. Here's a common
>>>> idiom:
>>>>
>>>> describe Person do
>>>> def valid_attributes
>>>> {:name => 'joe smith'}
>>>> end
>>>> before(:each) do
>>>> @person = Person.new(valid_attributes)
>>>> end
>>>> it "should be valid with valid attributes" do
>>>> @person.should be_valid
>>>> end
>>>> it "should be invalid with no name" do
>>>> @person.name = nil
>>>> @person.should_not be_valid
>>>> end
>>>> end
>>>>
>>> Using this as an example, if a new validation rule is added, this test will
>>> fail without indicating /why/. Sure, I can get that answer in other ways,
>>> but I'd hate to discover things like:
>>>
>>> it "should be valid with valid attributes" do
>>> # puts @person.errors if [EMAIL PROTECTED]
>>> @person.should be_valid
>>> end
>>>
>>> (Which I've seen when people have to repeatedly diagnose issues in a test;
>>> I'd prefer a failure message to the above)
>>>
>>>
>>>> Together, these different examples help to tell the whole story, and
>>>> when one example fails you know why it's failing - its just that the
>>>> message is in the example's name instead of a custom assertion
>>>> message.
>>>>
>>>> Make sense?
>>>>
>>> Yes and no; test isolation and good names is a decent practice even in
>>> XUnit, but clearly it's that much stronger in RSpec, and I'm in favour of
>>> that. However, I find that often test failures involve unexpected changes (
>>> e.g. the REST service didn't return a status code of 201, as you expected,
>>> because a validation rule changed and the validation failed), which aren't
>>> as easy to message.
>>>
>>> Still, i'm willing to give this approach a shot and see if this bothers me
>>> increasingly less.
>>>
>> Personally, I'm open to the idea of custom messages - I just have no
>> idea how that work syntactically. If you get to the point where you
>> really feel the need for that feature (or before that point) please
>> feel free to make suggestions about that.
>>
>
> What do you think about using a custom expectation matcher here?
> be_valid can be its own matcher instead of using the predicate
> matcher. That way we can include extra info without polluting the
> syntax, because as you said, this doesn't come up.
>
> Of course that gets in the way of other objects that respond to
> valid?, so I guess you could do a little bit of type-checking (if it's
> an AR object then display errors, otherwise delegate to predicate
> matcher) or create a separate matcher altogether.
>
> What about something like:
>
> it "should validate with valid attributes" do
> @person.should validate
> end
>
> 'Person should validate with valid attributes' FAILED
> expected object to validate, failed with errors:
> Age can't be blank
>
> Basically I think a custom expectation matcher works fine here, I just
> don't know the best way to implement it.
>
> Pat
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
Maybe this is what your thinking?
http://opensoul.org/2007/4/18/rspec-model-should-be_valid
-Ben
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
