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 came up with two ideas for reducing the amount of token passing required for the service methods and improving readability of manager tests. Conceptually, it makes sense to think of the service methods as operations on a context where the auth_token defines that context. It follows that the context should be established as a pre-condition to those operations and all subsequent operations perform within that context. In most cases the same auth token is used for multiple operations.
First Idea
Accept an auth_token as a constructor argument in ObjectManager that way unless one is specified as a keyword argument to the service method, the default (constructor argument) is used. Usage of the managers would then look a bit like..
user_manager=managers.UserManager(default_token)
user=user_manager.create('username', 'first_name', ... ) # create with user privilegesuser_manager.update(user.id, {'first_name': 'joe'})
user_manager.delete(user.id)
admin_user_manager=managers.UserManager(admin_token)
admin_user_manager.create('otheruser', 'other_name'...) # create with admin privileges
Second idea
Slightly more "magic" than above but has the benefit of being a drop in solution that doesn't have to be applied everywhere. It also wont require changes in object managers; only the call site of the service methods. The other benefit is that you can have the same manager instance decoupled from the auth token. My thoughts on this were that test cases which must perform an operation (ie. to seed test data) setup and call self.admin_abcxyz_manager which would be wrapped with an admin auth token.
I like this because it also helps with readability of the tests which could be drastically improved so that we know what we're actually testing. When you see a call to admin_abcxyz_manager you know it must succeed and that we are not testing the operation with this call. You also know that all calls to abcxyz_manager no longer assume the auth token is for admin which most currently do. The idea stems from cleanup I am working on for #39 to re-use all of the existing tests for verifying different roles. The tests will be written in a way which makes no assumption about the auth token being for the admin.
I came up with two ideas for reducing the amount of token passing required for the service methods and improving readability of manager tests. Conceptually, it makes sense to think of the service methods as operations on a context where the auth_token defines that context. It follows that the context should be established as a pre-condition to those operations and all subsequent operations perform within that context. In most cases the same auth token is used for multiple operations.
First Idea
Accept an auth_token as a constructor argument in
ObjectManager
that way unless one is specified as a keyword argument to the service method, the default (constructor argument) is used. Usage of the managers would then look a bit like..Second idea
Slightly more "magic" than above but has the benefit of being a drop in solution that doesn't have to be applied everywhere. It also wont require changes in object managers; only the call site of the service methods. The other benefit is that you can have the same manager instance decoupled from the auth token. My thoughts on this were that test cases which must perform an operation (ie. to seed test data) setup and call
self.admin_abcxyz_manager
which would be wrapped with an admin auth token.I like this because it also helps with readability of the tests which could be drastically improved so that we know what we're actually testing. When you see a call to
admin_abcxyz_manager
you know it must succeed and that we are not testing the operation with this call. You also know that all calls toabcxyz_manager
no longer assume the auth token is for admin which most currently do. The idea stems from cleanup I am working on for #39 to re-use all of the existing tests for verifying different roles. The tests will be written in a way which makes no assumption about the auth token being for the admin.Usage of this approach would make code like...
The text was updated successfully, but these errors were encountered: