On 9/4/07, Pat Maddox <[EMAIL PROTECTED]> 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
be_valid_model????
> 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
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
