[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(...)
> [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
Warning: should_not have_at_least is not supported"
The correct way should be:
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