Test Common Bundle Laravel Package

Getting Started

This is a test-support bundle, not a runtime dependency. Treat it as a dev-only utility that shipped alongside the Elcodi e-commerce suite around 2014.

Minimal steps:

composer require --dev elcodi/test-common-bundle

1. Install it with --dev; it should never appear in require.
2. Look first at the bundle's Test/ (or Tests/) directory in vendor/elcodi/test-common-bundle — that is where the abstract test-case classes and shared helpers live. There is effectively no public API beyond those classes.
3. Register the bundle only in your config_test.yml / AppKernel::registerBundles() test branch if it provides a test kernel or fixtures.
4. First real use case: make one of your bundle's test classes extend the provided abstract test case instead of hand-rolling Symfony kernel boot, container access, and fixture setup.

Be realistic about scope: with 0 stars, 0 dependents, and a 2014 release, you are reading source rather than documentation. The elcodi.io/docs link and Gitter channel are the only references, and both likely assume the full elcodi/elcodi monorepo.

Implementation Patterns

Subclass the base test case. The dominant pattern for this bundle is inheritance, not composition:

use Elcodi\TestCommonBundle\Test\AbstractWebTestCase; // verify actual FQCN in vendor/

class CartTest extends AbstractWebTestCase
{
    public function testCartIsEmptyOnCreation()
    {
        $cart = $this->getService('elcodi.cart');
        // ...
    }
}

Use it inside the monorepo, not standalone. Because this is a subtree split, the intended workflow is: clone elcodi/elcodi, run the full test suite, and let this bundle supply shared bootstrap. If you are consuming Elcodi components in your own app, extend Elcodi's abstractions from the component's own Tests/ folder rather than pulling this bundle in.

Shared kernel provisioning. Typical helpers you can expect (check the source to confirm names) include:

• a booted test kernel in the test environment,
• getService() / container accessors,
• fixture or entity-factory helpers for Elcodi entities (Cart, Product, User),
• assertion helpers for money/value objects and collections.

Integration pattern. Wire it together with PHPUnit via a bootstrap file that autoloads the vendor dir and starts the Elocdi test kernel once; the base class then reuses it across tests to avoid per-test kernel rebuilds.

Gotchas and Tips

• Read-only subtree split. Do not open PRs or issues here. All fixes go to elcodi/elcodi; this repo is regenerated from that subtree. Any local patch you make will be blown away on the next split.
• Abandonment risk is the headline. Last release 2014-08-14. Expect PHP 5.x-era code, Symfony 2.3/2.4-style kernels, and PHPUnit 3.x/4.x APIs (setUp() signatures, getMock() instead of createMock()). Installing on PHP 8 / Symfony 5+ will almost certainly fail or silently break.
• Composer will fight you. Run composer why-not elcodi/test-common-bundle and be prepared to add --ignore-platform-reqs or version pins. If resolution is painful, vendor the two or three abstract classes you actually need into your own tests/Support/ directory — given zero dependents and no maintenance, that is usually the cheaper path.
• Never in production autoload. Confirm the bundle is absent from your prod AppKernel; a stray registerBundles() entry in the production kernel will fail on missing dev dependencies after composer install --no-dev.
• Hidden coupling to Elcodi internals. Helpers will reference Elcodi-specific service IDs (elcodi.cart, entity namespaces, etc.). If you are not using the full Elcodi stack, these classes will throw on missing services — there is no graceful degradation.
• Debugging. Use phpunit --debug and check your bootstrap file first; most "class not found" errors here are an autoload/bootstrap mismatch rather than a bundle bug. Verify the actual namespace with grep -r "namespace" vendor/elcodi/test-common-bundle — the README gives no FQCNs.
• Extension point. The only sensible extension is subclassing a base test case and overriding its kernel/fixture setup. There is no configuration tree to speak of in a bundle this small.
• Verify before committing to it. With a score of 0.3 and no dependents, spend ten minutes reading the source before adding it to composer.json. If the base classes are thin, copying them is strictly better than depending on an unmaintained split.