Weave Code
Test Common Bundle Laravel Package
elcodi/test-common-bundle
Test Common Bundle is part of the Elcodi e-commerce suite of Symfony components and bundles under the MIT license. Read-only package; use the main elcodi/elcodi repository for issues, questions, and pull requests.
[READ-ONLY] Subtree split of the Elcodi TestCommon bundle
Frequently asked questions about Test Common Bundle
- Is elcodi/test-common-bundle a Laravel package?
- No. It is a Symfony bundle from the Elcodi e-commerce suite and a read-only subtree split of the main elcodi/elcodi monorepo. It ships no Laravel service provider, no facades, no config publishing, and no illuminate/* dependencies, so Laravel's container and kernel have no way to register it.
- Can I install elcodi/test-common-bundle in a Laravel 10 or 11 app with Composer?
- Composer may resolve it in principle, but the practical install is usually blocked by version constraints. The package is a 2014-era split with PHP and Symfony pins that conflict with the PHP 8.1+ and Symfony 6/7 requirements of current Laravel releases, which pushes teams toward --ignore-platform-reqs hacks. That is a strong signal to stop rather than force the dependency.
- What does elcodi/test-common-bundle actually contain?
- It holds shared testing utilities used by Elcodi's own component and bundle test suites, such as base test case classes, fixture builders, and helper assertions. It is not an e-commerce runtime library and exposes no storefront, cart, or checkout features. Treat it as reference test code, not application functionality.
- Does elcodi/test-common-bundle support PHP 8 and modern Symfony versions?
- Almost certainly not out of the box. The last release sits around version 0.3 with 2014-era metadata, so expect PHP 5.x constraints and Symfony 2.x component requirements. Check the package composer.json for php, symfony/*, and phpunit/phpunit constraints before you spend time on any integration attempt.
- How do I use the Elcodi test helpers inside a Laravel test suite?
- You generally do not use the package directly. Instead, read the helper classes, extract the reusable patterns such as base test case setup, fixture builders, and assertion helpers, and reimplement them against Laravel's testing APIs: TestCase, RefreshDatabase, model factories, and orchestra/testbench for package-level tests. Copying patterns under MIT attribution keeps your dependency graph clean.
- Is elcodi/test-common-bundle still maintained or abandoned?
- It is effectively unmaintained. The repository is a read-only subtree split whose banner states pull requests will not be reviewed, and all issues, questions, and PRs are redirected to the main elcodi/elcodi repository. With zero stars, zero dependents, and a 2014 last release, there is no field validation and no supported upgrade path.
- Are there security risks in requiring an abandoned Symfony bundle as a dev dependency?
- Yes, though the blast radius is smaller when it stays in require-dev. The main risks are inheriting transitive packages with no CVE response process, lockfile exposure if those packages are ever promoted, and resolution deadlocks that tempt teams into unsafe Composer flags. There is also no one accountable for patching an advisory.
- What Laravel-native alternatives replace what this bundle offers?
- Laravel's own tooling covers the same ground: Illuminate\Foundation\Testing for HTTP and database assertions, RefreshDatabase for state isolation, model factories for fixtures, and orchestra/testbench for testing packages. Pest or PHPUnit provides the runner and assertion layer, while Mockery and Faker handle doubles and fake data. Nothing in the Elcodi bundle is uniquely required.
- How do I copy or fork the Elcodi test utilities into my own project?
- The cleanest path is copy-and-adapt: vendor the useful helpers into tests/Support/ with an MIT attribution note in each file header, adding no runtime or dev dependency. If the extracted logic is substantial, fork it under your own organization, modernize the PHP, Symfony, and PHPUnit constraints, and publish it as an internal package. A direct Composer dependency should be the last resort.
- When would depending on elcodi/test-common-bundle actually make sense?
- Only in a legacy Symfony 2 application that already runs the Elcodi stack and needs the shared test base classes as-is. In that narrow case, pin to a stable tag and keep it in require-dev, isolated from production code. It is not a defensible dependency for any modern Laravel application.
Weaver
How can I help you explore Laravel packages today?