Skip to content
This repository has been archived by the owner on May 18, 2024. It is now read-only.

Commit

Permalink
added should_authorize_for 'macro' for the common controller expectation
Browse files Browse the repository at this point in the history
  • Loading branch information
@dnagir
dnagir committed Apr 18, 2012
1 parent 8fae9f3 commit 6072180
Show file tree
Hide file tree
Showing 2 changed files with 28 additions and 6 deletions.
5 changes: 5 additions & 0 deletions README.md
View file
Original file line number Original file line Diff line number Diff line change
Expand Up @@ -216,6 +216,11 @@ describe PagesController do
it "will always allow no matter what" do it "will always allow no matter what" do
post(:create).should be_success post(:create).should be_success
end end

it "checks the authorisation" do
should_authorize_for(:create, page)

This comment has been minimized.

Sign in to view

Copy link
@dnagir

dnagir Apr 18, 2012

Author Owner

Ideally I'd like to write something like 'allowy.should authorize_for(:create, page)' but not sure how to write a proper matcher.

This comment has been minimized.

Sign in to view

Copy link
@dchelimsky

dchelimsky Apr 18, 2012

Matchers are designed to pass/fail immediately, whereas message expectations are designed to pass/fail when they receive an unexpected message or at the end of the example if they never received the expected message. What you're looking for is not really a matcher, but a way to instrument the example with message expectations using matcher-like syntax. If that's what you really want, then just always return true from matches? and always return false from does_not_match? and set the expectations you want within those methods. You're basically breaking the should/matcher contract to do this, so please consider the confusion that will set in in 6 months when this matcher works differently from all other matchers.

Personally I'd probably just wrap the expectations in a normal method. Something like what you have, but named differently. Maybe expect_authorization_request(:create, page) or some such. WDYT?

This comment has been minimized.

Sign in to view

Copy link
@dnagir

dnagir Apr 18, 2012

Author Owner

Yeah, thanks. Totally agree. What I really need here is a shortcut for setting a very common expectation.

The reason I choose "should_authorize_for" is that it seems to be inline with RSpec's "should_receive".

But the problem here is that "should_authorize_for" doesn't have an explicit subject unlike "should_receive".

Maybe I should write something like "allowy.should_authorize_for", but then I would have to add a method to RSpec mock object which I'm not sure is a good idea.

So for now settled on "macro" style with "should_autorize_for" until something better will be suggested.
What do you think?

This comment has been minimized.

Sign in to view

Copy link
@dchelimsky

dchelimsky Apr 18, 2012

Actually, looking at the code below where should_authorize_for is defined, I wouldn't even wrap this. It's already a one liner, so you're saving very little code, and the things that differ from line to line still differ from line to line.

This comment has been minimized.

Sign in to view

Copy link
@dnagir

dnagir Apr 18, 2012

Author Owner

That's true. However in practice writing the expectation allowy.should_receive(:authorize!).with(:edit, page) is a bit harder to write and read than just should_authorize_for(:create, page) (or other similar alternative).

That's the only motive for wrapping it. I don't care exactly what method was called, what I care about is that thing was authorized.
I guess this is more of a philosophical reason than poorly technical if that makes sense to you.

This comment has been minimized.

Sign in to view

Copy link
@dchelimsky

dchelimsky Apr 19, 2012

I understand what you're saying, but I have a different philosophy. object.should_receive(:message).with(arg, arg) already means something to me. I don't have to think about it because it's just like any other expectation. So for me it's actually less readable to wrap it because I have to think about what that method does.

This comment has been minimized.

Sign in to view

Copy link
@dnagir

dnagir Apr 19, 2012

Author Owner

Ok. I see, that makes sense.
I still like the macro due to its simplicity and probably will keep it.
But will show how to do it with plan RSpec expectation: ac8d4f9.

Thanks a lot for the help, David.
post(:create)
end
end end


``` ```
Expand Down
29 changes: 23 additions & 6 deletions lib/allowy/rspec.rb
View file
Original file line number Original file line Diff line number Diff line change
Expand Up @@ -3,18 +3,35 @@
module Allowy module Allowy


module ControllerAuthorizationMacros module ControllerAuthorizationMacros
def ignore_authorization! extend ActiveSupport::Concern
before(:each) do
registry = double 'Registry' def allowy
registry.stub(:can? => true, :cannot? => false, :authorize! => nil, access_control_for!: registry) @controller.current_allowy
@controller.stub(:current_allowy).and_return registry end


def should_authorize_for(*args)
allowy.should_receive(:authorize!).with(*args)
end

def should_not_authorize_for(*args)
allowy.should_not_receive(:authorize!).with(*args)
end

module ClassMethods
def ignore_authorization!
before(:each) do
registry = double 'Registry'
registry.stub(:can? => true, :cannot? => false, :authorize! => nil, access_control_for!: registry)
@controller.stub(:current_allowy).and_return registry
end
end end
end end
end end


end end


RSpec.configure do |config| RSpec.configure do |config|
config.extend Allowy::ControllerAuthorizationMacros, :type => :controller config.include Allowy::ControllerAuthorizationMacros, :type => :controller
end end


1 comment on commit 6072180

@dnagir
Copy link
Owner Author

@dnagir dnagir commented on 6072180 Apr 18, 2012

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The related spec is at dc1b3c4

Please sign in to comment.