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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updates checkout tests to cover for out of stock variant #12423
Updates checkout tests to cover for out of stock variant #12423
Conversation
Adds out of stock check as helper
Regarding the first commit - adding the out of stock check - I'm thinking there are two possibilities:
There is no huge difference between the spec runtimes, taken from knapsack dashboard: but perhaps the |
As shared examoples, in guest_spec.rb
0d4bd68
to
729c5f0
Compare
This can be squashed with the first commit of this PR
All test cases are covered within the respective checkout step specs
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's a bit weird to be testing "logged" example in the guest_spec.rb
but it makes sense to have all these test next to the shared_example code, so I think that's an acceptable trade of.
馃憤
let!(:payment_with_fee) { | ||
create(:payment_method, distributors: [distributor], | ||
name: "Payment with Fee", description: "Payment with fee", | ||
calculator: Calculator::FlatRate.new(preferred_amount: 1.23)) | ||
} |
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.
Was this missing before ?
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.
Yes, this is missing in master.
The payment method used for this order currently comes from line 16, when the distributor is created:
let(:distributor) { create(:distributor_enterprise, charges_sales_tax: true) }
We're currently not checking payment fees appear on the summary step - we probably should...
Yes we are - I've checked this but totally forgot, in the meantime, this scenario is covered here (payment_spec), so because of that, we don't need to do that setup in the summary spec:
context "with a transaction fee" do |
It's a bit weird to be testing "logged" example in the guest_spec.rb but it makes sense to have all these test next to the shared_example code, so I think that's an acceptable trade of.
Thank you for validating this approach @rioug
@@ -66,4 +66,12 @@ def place_order | |||
click_on "Complete order" | |||
expect(page).to have_content "Back To Store" | |||
end | |||
|
|||
def out_of_stock_check(step) |
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 find the method name ambiguous. Does it check that something is out of stock or that nothing is out of stock?
When a test helper is mainly asserting expectations, I use that in the name. What about expect_out_of_stock
?
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.
Naming is indeed a whole science on its own. Thanks for that tip 馃檹
variant.on_demand = false | ||
variant.on_hand = 0 | ||
variant.save! |
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.
Did you try variant.update!(on_demand: false, on_hand: 0)
?
visit checkout_path | ||
end | ||
|
||
context "when a line item is out of stock" do | ||
before do | ||
variant.on_demand = false | ||
variant.on_hand = 0 | ||
variant.save! | ||
end | ||
|
||
it "returns me to the cart with an error message" do | ||
out_of_stock_check(:summary) | ||
end | ||
end |
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.
Just noting that we first visit the checkout, then something goes out of stock and then we visit another page. Visits are often expensive in specs. Could the first visit be skipped to save time?
context "when a line item is out of stock" do | ||
before do | ||
variant.on_demand = false | ||
variant.on_hand = 0 | ||
variant.save! | ||
end | ||
|
||
it "returns me to the cart with an error message" do | ||
out_of_stock_check(:payment) | ||
end | ||
end |
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 noticed that you follow this context pattern quite strictly. It's seen as good style by many people. I personally find that it's good for larger tests but find it much easier to write short tests in a simple it
block in this style:
it "alerts me about out of stock items" do
clear_stock_for_variant
visit step
expect_out_of_stock_message
end
Some people follow this clear three part structure for tests: setup, action, expectation. Just FYI, you don't have to change anything.
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.
Ok, that makes sense as well. I understand having the setup within the context block is more code lines - I feel it made my reading easier, when set up in this way. But I totally see the redundancy, for more experienced people.
I'll try to keep this in mind for next time. Thanks again 馃檹
if session == "logged" | ||
login_as(user) | ||
end |
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.
Instead of this conditional, you could just do the login in a context block outside of the shared examples.
We were missing tests to cover the scenario in which a variant on cart gets out of stock.
What? Why?
The PR checks that the correct redirect occurs, if a given variant is out of stock and the user proceeds or re-starts checkout.
I chose to follow this reasoning: the PR implements the test as shared examples for guest and logged user, in the
guest_spec.rb
, the fastest of all checkout specs. This keeps the code close and easier to read/maintain - albeit a bit out of context, as we do log in (within the guest spec 馃檲 ) - I hope this is acceptable.What should we test?
Release notes
Changelog Category (reviewers may add a label for the release notes):
The title of the pull request will be included in the release notes.
Dependencies
Documentation updates