-
-
Notifications
You must be signed in to change notification settings - Fork 730
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test inventory report to use variant overrides #3654
Test inventory report to use variant overrides #3654
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice!
order_cycle = create(:simple_order_cycle, suppliers: [supplier], distributors: [distributor], variants: [product.variants.first]) | ||
create(:variant_override, hub: distributor, variant: variant, price: 2) | ||
|
||
allow(subject).to receive(:params).and_return(distributor_id: distributor.id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a bad practice to stub the subject of the test because we are then not testing the actual implementation. Do you see a way to overcome this? I guess we need to pass a different set of params instead but I haven't checked the report's implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that it's bad practice. But I think fixing it is beyond this pull request.
- I used the same pattern as in the rest of the spec file. Solving this problem would be an improvement but it should be done for the whole file.
- The
params
method is not provided by this controller but by one of the ancestors. Rails provides it. That's why I think it's okay to stub it. Ideally, all that filtering would happen in a service that is taking the params as input and we didn't need to stub it.
@sauloperez Are you okay to leave this as is? I don't like to get into refactoring work which then creates merge conflicts. Let's be stricter once this Spree upgrade is done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine, let's just create a tech debt issue then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! 👍
What? Why?
Closes #3237
For the Spree v2 upgrade we want to make sure that all code is using variant overrides correctly. This PR adds a couple of specs to cover the products and inventory reports.
What should we test?
Spec only changes, no tests required.
I tested the new specs with master and 2-0-stable, both passing.