src/Sylius/Behat/Resources/config/suites/ui/taxation/applying_taxes.yml (1)

28-28: Context Addition: sylius.behat.context.setup.checkout.shipping Introduced
The insertion of the shipping context under the checkout setup (line 28) enhances the testing scope for taxation scenarios by incorporating shipping details. Please verify that this addition does not conflict with the existing sylius.behat.context.setup.shipping entry later in the list. It’s suggested to review execution order if context dependencies exist.

src/Sylius/Behat/Resources/config/suites/ui/order/managing_orders.yml (1)

38-39: Integrate Checkout Shipping Context in UI Orders Suite
The addition of - sylius.behat.context.setup.checkout.shipping ensures that shipping-specific configuration is applied during the checkout process in the UI orders suite. However, note that another shipping-related context (sylius.behat.context.setup.shipping on line 49) is already present. Please verify that these two contexts serve distinct purposes and do not cause redundant configuration or overlap.

src/Sylius/Behat/Resources/config/suites/api/shipping/viewing_shipping_methods.yml (1)

37-37: API Shipping Checkout Context Addition
The addition of - sylius.behat.context.api.shop.checkout.shipping improves the coverage of shipping functionality in the API suite for viewing shipping methods. Ensure that this context is distinct from UI contexts and correctly configured for API-specific scenarios.

src/Sylius/Behat/Resources/config/suites/api/order/managing_orders.yml (1)

38-38: API Order Management Shipping Setup
Incorporating - sylius.behat.context.setup.checkout.shipping in the API order management configuration aligns shipping setup with checkout processes. Confirm that its inclusion harmonizes with the existing contexts and does not duplicate the behavior provided by other related shipping contexts.

features/shop/checkout/placing_an_order_after_moving_back_in_checkout.feature (1)

27-27: Step Wording Refinement for Shipping Step
Changing the step to "When I go back to the shipping step" helps simplify the language and improve readability. Ensure that this change is reflected in the corresponding Behat context mappings and that there is no disruption in test execution.

src/Sylius/Behat/Resources/config/suites/ui/shipping/applying_shipping_fee.yml (1)

24-24: Augmenting UI Shipping Fee Setup with Checkout Shipping Context
The new entry - sylius.behat.context.setup.checkout.shipping integrates checkout-specific shipping configurations into the shipping fee suite. Double-check that it complements rather than conflicts with the generic shipping context declared later (e.g., at line 29) to prevent unintended duplication of setup routines.

features/hybrid/checkout/placing_order_on_multi_channel/placing_an_order_on_multiple_channels_with_same_currency.feature (1)

25-26: Inconsistent wording between similar scenarios

In the first scenario (lines 25-26), you updated the wording to "And I chose 'Free' shipping method and 'Offline' payment method" followed by "When I confirm my order". However, in the second scenario (lines 34-35), a similar step still uses "When I proceed with 'Free' shipping method and 'Offline' payment" followed by "And I confirm my order".

Consider updating the second scenario to match the first one for consistency:

-        When I proceed with "Free" shipping method and "Offline" payment
+        And I chose "Free" shipping method and "Offline" payment method
         And I confirm my order

Also applies to: 34-35

features/shop/checkout/paying_for_order/paying_offline_during_checkout.feature (1)

29-30: Check Gherkin syntax: consecutive 'When' steps

In the second scenario, there appears to be two consecutive "When" steps (line 29 and the preceding line). In Gherkin syntax, this is unusual and could potentially cause issues with test execution.

Consider changing one of them to use "And" to maintain proper Gherkin structure:

-        When I check the details of my cart
+        And I check the details of my cart
         And I confirm my order

Or alternatively:

         When I check the details of my cart
-        And I confirm my order
+        Then I confirm my order

features/shop/shipping/applying_shipping_fee/applying_correct_shipping_fee_on_order.feature (1)

28-29: Check Gherkin syntax: consecutive 'When' steps

In the second scenario, there are two consecutive "When" steps (lines 28-29). In Gherkin syntax, this is unusual and could potentially cause issues with test execution.

Consider changing one of them to use "And" to maintain proper Gherkin structure:

         When I want to complete the shipping step
-        When I decide to change shipping method
+        And I decide to change shipping method
         And I change shipping method to "FedEx"

src/Sylius/Behat/Context/Setup/Checkout/ShippingContext.php (1)

24-51: Well-structured new context class for shipping method selection.

This new class is well-designed with a clear, focused responsibility for choosing shipping methods during checkout in Behat scenarios. It properly leverages the command bus pattern and has clear method names.

Consider adding null check for shipments.

The code assumes that the order always has at least one shipment when accessing $order->getShipments()->first(). Consider adding a null check to prevent potential runtime errors if an order exists without shipments.

 public function chooseShippingMethod(ShippingMethodInterface $shippingMethod): void
 {
     /** @var OrderInterface $order */
     $order = $this->sharedStorage->get('order');
 
+    $shipment = $order->getShipments()->first();
+    if (null === $shipment) {
+        throw new \RuntimeException('Order has no shipments.');
+    }
+    
     $this->commandBus->dispatch(new ChooseShippingMethod(
         $order->getTokenValue(),
-        $order->getShipments()->first()->getId(),
+        $shipment->getId(),
         $shippingMethod->getCode(),
     ));
 }

src/Sylius/Behat/Context/Setup/Checkout/PaymentContext.php (1)

24-51: Well-structured payment context implementation.

The new PaymentContext class is well-organized with clear method names and appropriate use of attributes for step definitions. The implementation correctly handles different user roles (customer/visitor) and properly dispatches the payment method command.

One potential improvement to consider:

$order->getPayments()->first()->getId()

This assumes the order always has at least one payment and we always want to use the first one. Consider adding a check to handle cases where no payments exist, or adding flexibility for selecting specific payments when multiple are present.

src/Sylius/Behat/Context/Ui/Shop/Checkout/CheckoutPaymentContext.php (1)

40-41: Consider matching placeholders with parameter names for clarity.

The annotation placeholders use :paymentMethod, while the parameter name is $paymentMethodName. Although this is not a functional issue, keeping them consistent can improve readability.

src/Sylius/Behat/Context/Ui/Shop/Checkout/CheckoutShippingContext.php (4)

35-39: New step definition for navigating directly to the addressing step.
This method calls changeAddressByStepLabel(). Consider adding error handling or an assertion to confirm that the step label is present to avoid potential ElementNotFoundException.

---

51-52: Multiple step definitions for proceeding with a shipping method.
You’ve introduced two nearly identical steps for “the visitor” and “the customer,” both mapped to the same method. If there’s no functional difference, consider unifying them into a single step to reduce duplication.

---

88-92: Combined step definitions for shipping step actions.
These attributes handle different phrasings but trigger the same method. This can be helpful but may cause confusion if they diverge in the future. Consider whether a single step with parameter placeholders might be clearer.

---

455-457: Additional step definitions for changing shipping method through the UI context.
Reusing a single function for multiple step textual variations is consistent, but keep an eye on potential confusion if more complex logic is ever required for each scenario.

src/Sylius/Behat/Context/Api/Shop/CheckoutContext.php (1)

661-665: Assertion with a specific violation message for shipping method requirements.
The message “Product does not fit requirements...” is user-friendly but consider verifying grammar, e.g. “do not meet” instead of “does not fit” for multi-product messages.

features/shop/cart/shopping_cart/allowing_access_only_for_correctly_logged_in_users.feature (1)

55-60: Keep tag consistency for similar scenarios

Note that the scenario on line 55 still uses the @javascript tag while the similar scenario on line 106 now uses @mink:chromedriver. Consider standardizing these tags for similar scenarios.

src/Sylius/Behat/Context/Transform/CartContext.php (1)

53-60: 💡 Verification agent

🧩 Analysis chain

Verify backward compatibility of transformation changes.

The method has undergone significant changes:

1. Renamed from providePreviousCartToken to providePreviousCart
2. Return type changed from ?string to ?OrderInterface
3. Pattern simplified from /^((?:previous|customer|customer's|visitor's|their) cart)$/ to just /^(previous cart)$/
4. Implementation now directly queries the repository instead of checking shared storage

While returning an Order object is more semantically correct, these changes might impact existing tests that:

• Expected a token string return value
• Used patterns like "customer's cart" or "their cart"

---

🏁 Script executed:

#!/bin/bash
# Search for usages of the various cart patterns that might be affected
echo "Searching for usages of cart patterns that might be affected by the change:"
rg -A 1 -B 1 "previous cart|customer's cart|customer cart|visitor's cart|their cart" --glob "*.feature"

Length of output: 11242

---

Action required: Address potential backward compatibility issues with cart transformation changes

After reviewing the feature files, it’s clear that while the new transformation now only matches the literal phrase "previous cart", many scenarios (in files such as features/shop/checkout/preventing_from_claiming_cart_of_wrong_user.feature and several files under features/shop/cart/shopping_cart/) still reference variations like "customer's cart", "visitor's cart", and "their cart". This means that tests expecting these patterns or a token string (from the previous method signature) may now fail.

• The method rename from providePreviousCartToken to providePreviousCart and the change in return type from ?string to ?OrderInterface will break compatibility for tests expecting a token.
• The new regex /^(previous cart)$/ does not cover other phrases previously accepted. Review and update test scenarios or adjust the regex if backward compatibility is needed.
• Also, the repository query implementation now replaces direct shared storage checks, so tests may need to assert behavior against an OrderInterface object instead of a token string.

Please ensure that either the tests are updated to conform to the new behavior or the transformation is adjusted to handle all previously supported cart phrases.

src/Sylius/Behat/Context/Api/Shop/CartContext.php (1)

852-858: ⚠️ Potential issue

Critical security fix for guest cart access.

This hotfix prevents guests from adding products to a logged-in user's cart, addressing a potential security vulnerability.

features/shop/cart/shopping_cart/allowing_access_only_for_correctly_logged_in_users.feature (1)

110-111: ⚠️ Potential issue

Fix duplicate step with inconsistent perspective

There's a duplication with inconsistent perspective in these two consecutive steps. Line 110 uses third-person perspective ("the customer checks") while line 111 suddenly switches to first-person ("I check"). One of these lines should be removed.

-        When the customer checks the details of their cart
-        When I check the details of my cart
+        When the customer checks the details of their cart

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

        When the customer checks the details of their cart