-
-
Notifications
You must be signed in to change notification settings - Fork 724
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
[BUU] Activate admin_style_v3 for most system specs #11645
[BUU] Activate admin_style_v3 for most system specs #11645
Conversation
Ok, some |
Thanks Filipe! It looks like probably all of these failures are due to a style change in capitalisation, which results in text no longer matching. Eg:
I'm not sure of the most efficient way to solve this, but I've often thought that these expectations shouldn't be case-sensitive (they still convey the same meaning to the user), so I would argue that we change that. I'll raise in #core-devs. |
I discussed with Maikel, and agreed it's worth updating the text in the specs to be more readable and better match what's on the screen. We also agreed that it's helpful to optionally add a matcher like @filipefurtad0 would you like to try this, or perhaps hand over for a |
Happy to have a go at this 👍 |
a5e5209
to
c50219e
Compare
Hum, indeed there are some failing tests now. I've left this one forgotten in In Dev, but now of course the code has changed (after rebasing). Either way, even after fixing, I guess we'll only be able to merge this PR once we're ready to release the feature, right? So, maybe we should hold this one for a while... And update everything once we're ready to release BUU. What do you think @dacook ? |
🤔 Hmm.
We could run the specs twice, for both old and new. So I agree, let's keep this PR in dev, and wait until we get closer to releasing admin_style_v3. We can occasionally refresh this branch when needed until then. |
50f4af8
to
67c4768
Compare
Ok, great - thanks. I've updated it with a few changes so it's green again. |
67c4768
to
d8313b8
Compare
Ok, I've fixed conflicts, rebased, updated a test - it's green again. It seems to me the challenge now, is to migrate the relevant tests from the legacy products page into the spec for new product page; After that, we can delete the legacy spec file. Does this sound like a good plan @dacook? |
66d6103
to
1cc7bc4
Compare
Awesome, thanks Filipe! I've created an issue for this: I think we shouldn't delete the legacy spec until we remove the feature toggle. |
2f2c300
to
93dd4c8
Compare
e5bdc85
to
4c8f8dc
Compare
on the New variant button This test needs to be improved as, for Capybara, the text seems to be always visible, although it only does become visible by hovering.
This feature does not exist in BUU Replaces previous add variant button click with correct version
These seem to have been changed since the previous rebase.
I'm not sure why it's not appearing on my computer, but it was an unnecessary duplicate message, so I'm happy to remove it.
3d9ea3f
to
eccc6f4
Compare
Hi @filipefurtad0 , I went ahead and rebased this to prepare for merge. I condensed some of the past commits, and added some more fixes. |
It breaks due to a change of the spec environment. There's no point fixing it, it's no longer required.
eccc6f4
to
b1aafbf
Compare
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.
Although the latest changes are mine, I'm approving to resolve the "changes requested".
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.
Looks good !
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.
Huge chunk of work. Well done for taming this.
There are many little bits I would have like to see improved in the history but this needs to be merged as soon as possible to avoid more rebase errors.
it "displays a message when number of products is zero" do | ||
visit spree.admin_products_path | ||
|
||
expect(page).to have_text "No products yet. Why don't you add some?" | ||
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.
The main commit message doesn't reflect the commit content.
# Click dismiss on distributor warning | ||
click_button 'Dismiss' |
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.
Or we could setup the enterprise properly to avoid the warning?
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.
Done in #12652 🙏
# overlapping warning, we need to use 'node.trigger("click")' | ||
page.find(:button, "Save").trigger("click") |
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.
Can we dismiss the warning first? Otherwise this is a UX issue. Users can't "find button and trigger save" with their mouse.
spec/system/admin/order_spec.rb
Outdated
<<<<<<< HEAD | ||
expect(page).not_to have_content different_shipping_method_for_distributor1.name | ||
======= | ||
expect(page).to_not have_content different_shipping_method_for_distributor1.name | ||
dismiss_warning | ||
>>>>>>> 2ddec2cff4 (Deals with overlapping elements) |
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.
Another conflict that could have been squashed.
within(:xpath, '//*[@id="products-form"]/table/tbody[1]/tr[1]/td[5]/div') do | ||
expect(page).to have_content "On demand" | ||
end | ||
within(:xpath, '//*[@id="products-form"]/table/tbody[2]/tr[1]/td[5]/div') do | ||
expect(page).to have_content "20" # displays the total stock | ||
end | ||
within(:xpath, '//*[@id="products-form"]/table/tbody[2]/tr[2]/td[5]/div') do | ||
expect(page).to have_content "16" # displays the stock for variant_2 | ||
end | ||
within(:xpath, '//*[@id="products-form"]/table/tbody[2]/tr[3]/td[5]/div') do | ||
expect(page).to have_content "4" # displays the stock for variant_3 | ||
end | ||
expect(page).to have_content "On demand" | ||
expect(page).to_not have_content "20" # does not display the total stock | ||
expect(page).to have_content "16" # displays the stock for variant_2 | ||
expect(page).to have_content "4" # displays the stock for variant_3 |
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 think that the previous selectors were to avoid false passes of the spec. Imagine this spec running with Enterprise 4. It would show the number 4 even without displaying that 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.
Do you think we should revert to the xpath code? Maybe an alternative would be to include the count: 1
attribute/condition, or even make the on_hand
numbers a bit more specific, like 111, 222, 333 - I know, in theory, we could still have Enterprise 111, but maybe more unlikely.
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, I would go back to the xpath. If this was a more common use case then I would create helpers for that. Aren't there some helpers for accessing table rows by a displayed name, for example? That would be better.
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, in fact the inputs have labels associated with them, so something like this should work:
within row_containing_name("variant name") do
expect(page).to have_field "On demand", checked: true
expect(page).to_not have_field "On Hand", with: 20
end
(hmm, we need to fix that inconsistent capitalisation..)
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.
Sorry, that was targeting the fields inside the popout.
If we want to check the display, we can target the button (which opens the popout):
within row_containing_name("variant name") do
expect(page).to have_button "On Hand", with: "On demand"
expect(page).to_not have_button "On Hand", with: 20
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.
Even better might be to say something like this. But as far as I know Capybara doesn't have a convenient way to check all text (including button labels). We could make a helper for that, but it's not worth the bother..
within row_containing_name("variant name") do
within column("On Hand") do
expect(page).to have_text "On demand"
expect(page).to_not have_text "20"
end
end
What? Why?
!! Not to be merged just yet, as it activates BUU by default !!It does not yet fully address feature parity, I've disconnected the issue #11845
base_spec_helper.rb
;In what #11845 concerns, this is the current state (this will be updated as progressed):
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
This can be done once we have completed all BUU1 features, including:
Documentation updates