[rspec-users] New RSpec methods to Object proposal: should_all and should_none

Rodrigo Rosenfeld Rosas lbocseg at yahoo.com.br
Wed Dec 9 18:40:37 EST 2009

Rick DeNatale escreveu:
> On Wed, Dec 9, 2009 at 1:15 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
>> On Wed, Dec 9, 2009 at 11:55 AM, Pat Maddox <mailinglists at patmaddox.com> wrote:
>>> [@admin, @allowed_user].should all(be_allowed_to_visit(url))
>>> [@admin, @allowed_user].should all_be_allowed_to_visit(url)
>>> I prefer the first so as not to introduce more "magic" but if it catches on
>>> then moving to the second might be worthwhile.
>> Seems like there are a few approaches to syntax that might work, but
>> we also have to consider failure messages. Either of Pat's suggestions
>> would make it easier to provide a meaningful failure message.
>> Something like:
>> Expected <#User @role => 'admin'>, <#User @role => 'allowed'> to be
>> allowed to visit /some/path:
>> - <#User @role => 'allowed'> was not
>> - <#User @role => 'admin'> was
> I like Pat's idea too, but
> [x, y, z].should_not all_be_allowed_to(...)
> doesn't seem to be the same thing as
> none_of(x, y, z).should be_allowed_to(...)
> maybe
> [x, y, z].should all_not_be_alllowed_to(...)
> but I'm not sure

I was just thinking about that. Maybe "all" should be documented as in 
"should have_at_least(number).items
Warning: should_not have_at_least is not supported"

The correct way should be:

@collection.should none(be_allowed_to(...))

Of course the "none_of" syntax would be easier to read, but the option 
above is also acceptable in my opinion...

Faça ligações para outros computadores com o novo Yahoo! Messenger 

More information about the rspec-users mailing list