You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been hacking away at helpers to be able to write and run flexible Resource testing from resource_specs, rather than request_specs, because it makes testing a lot cleaner and easier. (Unfortunately, the mostly excellent jsonapi-resources seem to largely miss out describing how to work with resources and resource operations directly)
One thing that occurred to me in the process (now that I have nice JSONAPI::OperationResults to work with in my specs) is:
If jsonapi-authorization could somehow tag the resource (or the OperationResult, or something related and accessible) with the names/symbols of the various Pundit policy methods (relationship_method) and scopes that were applied during the authorization phase, this would make for really nice linking to the policy_specs, and assurance that all the right rules are being applied, without having to repeat some of the the auth-test-logic again further up the stack.
e.g. things like if policy.respond_to?(relationship_method) which mean a typo could result in a well tested policy method not actually being used by jsonapi-authorization when expected.
It'd be so nice to be able to check something like: expect(resource.policy_authorizations).to include(:create_with_widget) in a resource spec.
NB: (just top-of-head rambling from here on) Taken to the extreme, if could go a couple of levels deeper:
Something like this might also make it a lot quicker for newcomers to get up to speed with the Rails jsonapi/pundit suite - I know it would have helped me a lot to get that insight into what was going on, when I was struggling to get to grips with JR (and, less awkwardly, Pundit) at the same time.
The text was updated successfully, but these errors were encountered:
Thanks for the idea! I can't really grasp how an implementation for this could look like, but if you'd be OK to give this some time and hack on a proof-of-concept of how this would look like in jsonapi-authorization, I think I'd be able to form an opinion on that. Don't get your hopes up on it getting merged, though — implementing this might be too difficult or complex, and supporting it might not be easy. I'll be very happy if I'm proven wrong, though 😉
Hi.
Firstly, thanks so much for this gem!!
I've been hacking away at helpers to be able to write and run flexible Resource testing from resource_specs, rather than request_specs, because it makes testing a lot cleaner and easier. (Unfortunately, the mostly excellent jsonapi-resources seem to largely miss out describing how to work with resources and resource operations directly)
One thing that occurred to me in the process (now that I have nice JSONAPI::OperationResults to work with in my specs) is:
If jsonapi-authorization could somehow tag the resource (or the OperationResult, or something related and accessible) with the names/symbols of the various Pundit policy methods (relationship_method) and scopes that were applied during the authorization phase, this would make for really nice linking to the policy_specs, and assurance that all the right rules are being applied, without having to repeat some of the the auth-test-logic again further up the stack.
e.g. things like
if policy.respond_to?(relationship_method)
which mean a typo could result in a well tested policy method not actually being used by jsonapi-authorization when expected.It'd be so nice to be able to check something like:
expect(resource.policy_authorizations).to include(:create_with_widget)
in a resource spec.NB: (just top-of-head rambling from here on) Taken to the extreme, if could go a couple of levels deeper:
Something like this might also make it a lot quicker for newcomers to get up to speed with the Rails jsonapi/pundit suite - I know it would have helped me a lot to get that insight into what was going on, when I was struggling to get to grips with JR (and, less awkwardly, Pundit) at the same time.
The text was updated successfully, but these errors were encountered: