[Behat] Reuse common setup contexts in API and UI (in shipping order and related scenarios)#17816
[Behat] Reuse common setup contexts in API and UI (in shipping order and related scenarios)#17816GSadee merged 20 commits intoSylius:2.0from
shipping order and related scenarios)#17816Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
❌ Preview Environment deleted from BunnyshellAvailable commands:
|
features/shop/checkout/shipping_order/returning_from_shipping_step_to_addressing_step.feature
Show resolved
Hide resolved
...hipping_order/seeing_shipping_method_when_at_least_one_unit_match_to_shipping_method.feature
Show resolved
Hide resolved
b0d6920 to
5feabf1
Compare
Given I added vs When I add - ShippingGiven I added vs When I add - Shipping
5feabf1 to
de5f8f9
Compare
Given I added vs When I add - Shippingshipping order and other scenarios to reuse common setup contexts for both API and UI
shipping order and other scenarios to reuse common setup contexts for both API and UIshipping order and related scenarios)
de5f8f9 to
47c2f40
Compare
47c2f40 to
bd565a6
Compare
| Scenario: Seeing payment state as paid on orders list | ||
| When I browse orders | ||
| Then the order "#00000666" should have order payment state "Paid" | ||
| Then the last order should have order payment state "Paid" |
There was a problem hiding this comment.
Why? It could have stayed as it was 🤔
There was a problem hiding this comment.
It’s because of this unusual setup where we first place the order and only afterward add the product and address it. That’s why I decided to simplify it. Also, as a customer, we can’t choose the order number ourselves, so in such a scenario it should be something like #00000001 (which matches the last order) rather than #00000666. wdyt?”
...cing_order_on_multi_channel/placing_an_order_on_multiple_channels_with_same_currency.feature
Outdated
Show resolved
Hide resolved
features/shop/cart/shopping_cart/allowing_access_only_for_correctly_logged_in_users.feature
Outdated
Show resolved
Hide resolved
features/shop/cart/shopping_cart/allowing_access_only_for_correctly_logged_in_users.feature
Outdated
Show resolved
Hide resolved
features/shop/cart/shopping_cart/allowing_access_only_for_correctly_logged_in_users.feature
Outdated
Show resolved
Hide resolved
features/shop/cart/shopping_cart/allowing_access_only_for_correctly_logged_in_users.feature
Outdated
Show resolved
Hide resolved
features/shop/cart/shopping_cart/allowing_access_only_for_correctly_logged_in_users.feature
Outdated
Show resolved
Hide resolved
features/shop/cart/shopping_cart/allowing_access_only_for_correctly_logged_in_users.feature
Outdated
Show resolved
Hide resolved
src/Sylius/Behat/Context/Api/Shop/Checkout/CheckoutShippingContext.php
Outdated
Show resolved
Hide resolved
4ca2fc5 to
22f50a1
Compare
1e78ba7 to
960ff97
Compare
2e456cf to
0548159
Compare
0548159 to
e9bc43c
Compare
| Given the customer logged in | ||
| Given the customer added product "Stark T-Shirt" to the cart | ||
| When the customer checks the details of their cart | ||
| When I check the details of my cart |
There was a problem hiding this comment.
| When I check the details of my cart |
| When the visitor specify the email as "jon.snow@example.com" | ||
| And the visitor specify the billing address as "Ankh Morpork", "Frost Alley", "90210", "United States" for "Jon Snow" | ||
| Given the visitor added product "Stark T-Shirt" to the cart | ||
| When the visitor specify the billing address |
There was a problem hiding this comment.
| When the visitor specify the billing address | |
| When the visitor specifies the billing address |
| And the visitor specify the billing address as "Ankh Morpork", "Frost Alley", "90210", "United States" for "Jon Snow" | ||
| Given the visitor added product "Stark T-Shirt" to the cart | ||
| When the visitor specify the billing address | ||
| And the visitor specify the email as "guest@example.com" |
There was a problem hiding this comment.
| And the visitor specify the email as "guest@example.com" | |
| And the visitor specifies the email as "guest@example.com" |
| When the visitor specify the email as "guest@example.com" | ||
| And the visitor specify the billing address |
Continuation of:
Given I addedvsWhen I add#17785SaveContextfor more flexible suite configuration management #17783Until now, the checkout-related scenarios have been set up as follows:
• UI – via web actions (e.g.
Given I have a product ...actually triggered browser actions to prepare the initial step),• API – a mix of messenger commands and API calls.
During the development of Sylius 2.0, with the introduction of dynamic components, all scenarios involving product-related actions had to be marked as JS to work correctly. This significantly increased build time and reduced overall stability.
This PR focuses on decoupling the Behat architecture to unify the test setup for both UI and API. The goal is to eliminate most JS tags, which should lead to greater stability. Some performance improvements are already noticeable.
This PR doesn’t yet include all refactored scenarios, but at this stage we already observe the following performance gains:
• For non-JS scenarios, the timing is likely similar — some JS scenarios have been converted to non-JS, but at the same time, we benefit from faster setup thanks to the refactor (using messenger commands instead of API calls or UI interactions to prepare tests).
• For JS scenarios executed via Chromedriver, the same applies — some Panther scenarios have been switched to Chromedriver, and performance remains comparable.
JS with Panther: ~30 min → ~20 min