Weave Code
Test Application Laravel Package
sylius/test-application
Sylius Test Application provides a ready-made Sylius ecommerce environment for package development, with a minimal application skeleton and configuration for running functional tests and validating Sylius components and plugins in realistic conditions.
At a glance
Frequently asked questions about Test Application
- Is sylius/test-application a Laravel package?
- No. It is a Sylius application built on Symfony, using Symfony dependency injection, Doctrine, and the Sylius plugin model, none of which map onto Laravel. If your project is a Laravel application, do not add it as a dependency; at most treat it as a reference pattern for building version-agnostic test fixture apps.
- How do I install sylius/test-application with Composer?
- Add it as a require-dev dependency on a branch, since the project is organised as one branch per Sylius major. Pick the branch that matches the Sylius major your plugin or bundle targets, for example the 2.1 line today or the 2.2 line once you upgrade. Keep it out of production requirements because it is a development-only test harness.
- Which Sylius version does each branch of the test application support?
- Each branch is pinned hard to a single Sylius major rather than resolving constraints flexibly. The 2.2 branch, for instance, explicitly locks Sylius to 2.2, and 2.2.0-ALPHA.1 is a pre-release of that line. That means choosing the right branch is a branch-selection decision, not a Composer constraint-resolution one.
- Can I use this to test Laravel ecommerce packages or Laravel bundles?
- No. The harness boots a Symfony kernel with Sylius bundles and Doctrine, so it cannot host Laravel service providers, Eloquent models, or Laravel test primitives. Laravel teams should skip integration entirely and, if anything, borrow the per-major fixture app idea for their own test tooling.
- Should I use the 2.2.0-ALPHA.1 release in my shared CI pipeline?
- Not in the shared baseline. Pin stable tags for the pipeline that gates merges, and consume the alpha only in an isolated, non-blocking job that pre-validates an upcoming Sylius 2.2 upgrade. Promote the alpha to the shared pipeline only once a stable 2.2 tag is published.
- How does the test application help with functional and integration testing of Sylius plugins?
- It provides a preconfigured Sylius and Symfony application skeleton with a test-focused kernel and configuration, so you can exercise a plugin against a realistic ecommerce stack. Database setup, fixtures, and container wiring are already in place, which removes the need for every plugin repository to hand-roll its own fixture application.
- Does sylius/test-application replace sylius/plugin-skeleton test tooling?
- Evaluate it as a replacement rather than an addition. Running both the skeleton tooling and this harness side by side risks drift between two test environments and doubles maintenance. Migrate plugin test suites one Sylius major at a time, keep the legacy harness until parity is demonstrated, then delete the old fixtures.
- How should I handle branch selection when upgrading to a new Sylius major?
- Codify a branch-per-Sylius-major mapping in your CI configuration so the harness branch always matches the Sylius version under test. When you move the plugin to a new major, switch the harness branch in the same change, and keep the previous branch available until the upgrade is proven. Avoid mixing branches across jobs in the same matrix.
- Will the harness work with the PHP versions my project targets?
- You need to verify it per release, because each branch ships a locked constraint set that includes specific PHP and Symfony ranges. Check the branch's locked Sylius constraint against your own support matrix inside CI, and record the Symfony and PHP versions each release asserts. That way upgrades stay deliberate rather than accidental.
- Is sylius/test-application well maintained and safe to depend on?
- It is owned by the Sylius organisation, MIT licensed, and dev-only, so the blast radius is small and there is no production surface. Maintenance looks healthy, with automated upmerges between the 2.1 and 2.2 branches and active maintainers behind it. The residual risks are that the 2.2 line is still alpha and that you must track which branch maps to which Sylius major.
Weaver
How can I help you explore Laravel packages today?