Base Test Bundle Laravel Package

Getting Started

This bundle is test infrastructure, not a feature bundle. It ships base test-case classes so you can boot a Symfony2 kernel, grab the container, and drive the test client without inheriting Symfony's own WebTestCase constraints.

1. Install as a dev dependency. There are no tagged releases after 2014, so pin an explicit commit rather than floating on dev-master:

   composer require --dev instaclick/base-test-bundle:dev-master#<commit-sha>
   

2. Register it only in the test environment inside app/AppKernel.php:

   if (in_array($this->getEnvironment(), array('test'))) {
       $bundles[] = new IC\Bundle\BaseTestBundle\ICBaseTestBundle();
   }
   

3. Look first at the bundle's Test/ directory. That is where the base classes live (a WebTestCase for functional tests and typically a unit-oriented base case). Read getKernelClass(), createKernel(), and createClient() before writing anything else — those are the hooks you will override.
4. First use case: a functional smoke test. Extend the bundle's web test case and let it handle kernel boot:

   use IC\Bundle\BaseTestBundle\Test\WebTestCase;
   
   class HomepageTest extends WebTestCase
   {
       public function testHomepageIsReachable()
       {
           $client = $this->createClient();
           $client->request('GET', '/');
           $this->assertTrue($client->getResponse()->isSuccessful());
       }
   }
   

If the class namespaces differ in your checkout, trust the source over the README — the docs are from the Symfony 2.1–2.3 era.

Implementation Patterns

• Functional requests via the client. Use createClient() per test, call $client->request(...), then assert on getResponse(), getCrawler(), and redirects. This mirrors Symfony's WebTestCase but lets the bundle control how the kernel is booted and reused.
• Service-level integration tests. Boot the kernel without a client when you want to exercise a service against real dependencies:

  $kernel = $this->createKernel();
  $kernel->boot();
  $service = $kernel->getContainer()->get('acme.mailer');
  

  This is the "lower level" value prop — you are not forced through HTTP to test wiring.
• Custom kernel per bundle. Override getKernelClass() or createKernel() in your own abstract base test case so every test in a bundle boots the same environment (e.g., test, debug=false) and the same cache path:

  protected function getKernelClass()
  {
      return 'Acme\TestBundle\Test\AppKernel';
  }
  

• Build a project base class. Since this bundle gives you hooks, not fixtures, create Acme\TestBundle\Test\FunctionalTestCase extends WebTestCase in your project and centralize: kernel boot, DB truncation, mailer reset, and authentication helpers. Every bundle test then extends that.
• Data providers + kernel. Keep @dataProvider methods free of container access; boot the kernel in setUp() only, so data providers (which run before setUp) never touch services.
• Group by cost. Tag functional tests @group functional and run them separately from unit tests in CI; kernel boots dominate runtime.
• Reuse the kernel within a test class when the bundle supports it (check setUp/tearDown behavior). Rebooting per test is correct but slow; only share when your tests don't mutate container state.

Gotchas and Tips

• Symfony2-only, effectively frozen. Last release 2014-11-27. The kernel API, PHPUnit version expectations, and autoloading style predate Symfony 3/4/5. Do not attempt to use this on a modern Symfony app — write your own base test case instead. Its value today is as a reference pattern.
• No SemVer tags. composer require instaclick/base-test-bundle may resolve oddly; pin a SHA or a dev-master alias with a commit hash to keep builds reproducible.
• Register in test only. Registering in prod/dev wastes autoload and can surprise you if the bundle's compiler passes assume test-only context.
• Cache masking. Kernel boots reuse app/cache/test. If a config or container change isn't reflected, clear that cache manually — bin/phpunit won't always do it for you.
• It does not manage your database. No fixture loading, no schema creation. You still need Doctrine/DBAL setup and your own setUp truncation. Treat the bundle as kernel/client plumbing only.
• Extension points are method overrides. createKernel(), createClient(), and getKernelClass() are your seams. Everything else (mailer assertions, DB reset, auth) belongs in your project-level base class, not in this dependency.
• Debugging boot failures. Kernel boot exceptions are often swallowed by PHPUnit's output. Run a single test with --debug and inspect app/logs/test.log; a missing bundle registration or bad parameters_test.yml is the usual culprit.
• Autoload quirks. This is PSR-0-era code. If classes aren't found, check the bundle's composer.json autoload mapping and confirm app/autoload.php registers the namespace before debugging your own test code.
• Version drift across PHPUnit. The base class was written against PHPUnit 3.x/4.x semantics. Running it under PHPUnit 6+ requires overriding setUp() signatures yourself — budget for that if you're keeping it around.