Add tests for every scenario of the relationship operations#47
Add tests for every scenario of the relationship operations#47
Conversation
Without this, new allow_action/disallow_action calls for the same record would accidentally override and disable the previous stubs
This allows us to see that there might be some cases untested. Now the test names show that there might be a matrix of different cases that should be tested
These tests seemed to be missing in the original pull request. This commit is what all the other previous commits for spec changes and stubbing changes were leading up to
When both methods aren't stubbed, the mocking is unhelpfully bypassed and the policy acts like the other method wouldn't be present at all.
fc64038 to
5e51e82
Compare
|
Review from @lime or @matthias-g would be appreciated I added you as a collaborator now, @matthias-g 🎉. All pull requests will need a review before merging, so if you want to help you can review open pull requests, too, and give comments to help the PRs advance. You'll notice that we now also have a few labels — these are similar to what we use internally at Venuu, so let me walk through them quickly: Type labelsThese labels allow us to distinguish issues and PRs from each other. It's OK if a PR or an issue doesn't have any type label set.
Status labelsThese are labels that would be set by the PR author, if it would be possible. They allow us to see when the PR is in need of a review or other help.
Review labelsThese labels allow us to quickly see what the review status of a PR is. These are set by the reviewer to show the review status.
|
matthias-g
left a comment
There was a problem hiding this comment.
Looks good to me. Thanks for checking for and adding the missing cases!
|
Thanks for the review :) |
We want to make sure the tests for the new cases match all the possible cases:
update?update?update?I needed to do some refactoring with the stubbing logic to make it work correctly for all these cases.