The best approach to keep Sylius tests aligned with customized App

Hi All!

Long story short. My challenge is to keep Sylius tests aligned and updated with my customized App. I successfully introduced new states and new transition between “cart” and “ready” Shipping states, but this leads to a lot of failures in built in Sylius (Behat) tests. My workaround was to override those suites in my App conf, but it’s not satisfying because it results in a lot of duplicated code.

E.g. after changing above, all tests from feature:

vendor/sylius/sylius/features/account/customer_account/viewing_orders_history/viewing_shipment_status_on_a_placed_order_show_page.feature

will fail, because my new state for placed order (Shipment) is Packing and Behat expects it to be Ready.

To solve this I have created custom viewing_shipment_status_on_a_placed_order_show_page.feature, new custom OrderContext to handle “Given this has already been packed” and overridden api_customer_account and ui_customer_account suites in my App. What I don’t like with this approach is that whole configuration for api_customer_account and ui_customer_account is almost a copy of vendor Sylius suite - the only difference is my additional custom OrderContext. Moreover the vendor/sylius/sylius/features/account/customer_account/viewing_orders_history/viewing_shipment_status_on_a_placed_order_show_page.feature will keep failing as it follows outdated state flow.

Main problem is I have to do the same with many others features, which quickly will lead to duplicating almost all Sylius suites configuration which I want to avoid.

What is the best approach to keep Sylius tests working in such a case?

Thank You!

Hi @piotrmlodzianko

I’m not a very Sylius/Symfon/Behat expert. But from a requirements point of view, I think you simply can ignore the Sylius tests, because you have changed the requirements according to your needs. So you just need to write a new test which covers exactly your requirements and that’s it. No need to execute also the Sylius tests, because they have another “base of requirements” which they test.

Maybe you can use some “common Sylius test infrastructure” code like test data/fixtures setup code, etc. but the main requirements would be tested through your new tests and not the Sylius tests.