Alice Bundle Extension Laravel Package

Getting Started

AliceBundleExtension is a thin bridge: it wires hautelook/alice-bundle into Behat so a step definition can persist entities described in Alice YAML instead of hand-rolling new Post(); $em->persist(...). Day to day it saves you from writing a bespoke "given there are N posts" factory for every entity in your domain.

Compatibility gate first. The last release was 2016-06-07 and the repo is archived. That means PHP 5.5–7.x, Behat 3.0–3.3, Symfony 2.7/3.0 and hautelook/alice-bundle ~1.0. Before writing a line of code:

composer show -a theofidry/alice-bundle-extension   # see the real constraint
composer require --dev theofidry/alice-bundle-extension --dry-run -v

If Composer's solver reports a conflict against your Symfony/Behat version, stop here — the package has 0 dependents and no maintainer, so you will be reading the source to fix it, not opening an issue.

Where to look first, in this order:

1. vendor/theofidry/alice-bundle-extension/README.md — the only usage documentation that exists.
2. composer.json's require block — this is your compatibility truth, not the README.
3. ls src/ — everything ships in one namespace; the Behat-facing classes live under a Behat/ sub-namespace. That directory listing tells you whether you get a Behat Extension (register it in behat.yml) or a context trait/mixin (no registration, just use it).

First use case worth building: a feature file that needs a realistic domain, e.g. three published posts by a known author plus one draft, where a later step navigates to the author page and asserts only the published ones appear. That is exactly the shape of test where hand-written fixtures rot fastest and Alice earns its keep.

Implementation Patterns

Boot the kernel in your context. The extension gets its entity manager from the container, so your FeatureContext must be kernel-aware. With behat/symfony2-extension:

# behat.yml
default:
  extensions:
    Behat\Symfony2Extension: { kernel: { env: test, debug: true } }
  suites:
    default:
      contexts: [ AppBundle\Features\Bootstrap\FeatureContext ]

class FeatureContext implements Context, KernelAwareContext
{
    use KernelDictionary;
    use AliceContext; // name comes from src/Behat in your pinned version
}

Scenario-scoped loading, not suite-scoped. Load fixtures in a hook before each scenario and purge after, so tests stay independent:

/** @BeforeScenario */
public function loadFixtures(ScenarioScope $scope)
{
    $file = sprintf('%s/fixtures/%s.yml', __DIR__, $scope->getScenario()->getTags()[0] ?? 'default');
    $this->loadFixturesFrom($file);
}

/** @AfterScenario */
public function purge()
{
    $this->get('hautelook_alice.doctrine.purger')->purge();
}

Name your fixtures and reference them across steps. Alice object references (@user_1) are the whole point — persist once, then look the object up by name in later steps rather than re-querying the database by email.

AppBundle\Entity\User:
  user_alice:
    email: [email protected]
    roles: [ROLE_USER]
  user_{1..5}:
    email: <email()>

AppBundle\Entity\Post:
  post_published_{1..3}:
    title: <sentence()>
    author: '@user_alice'
    publishedAt: <dateTimeBetween('-1 year', 'now')>
  post_draft:
    title: 'Not ready'
    author: '@user_alice'
    publishedAt: null

Parameterise per scenario instead of duplicating YAML. Most fixture files differ only in a couple of scalars; pass overrides into the load call rather than forking the file. This keeps one canonical default.yml per domain concept.

Prefer Faker expressions over hardcoded values for anything rendered in a view. Hardcoded strings hide escaping bugs and create brittle selectors; <sentence()> plus a stable, explicit title only where a step actually asserts on it is the right balance.

Reuse the bundle's service ids. Loading through the same services the console command uses means your Behat fixtures and your hautelook_alice:doctrine:fixtures:load dev fixtures behave identically — same persister, same Faker providers, same processors. Don't instantiate Nelmio\Alice\Fixtures by hand.

Gotchas and Tips

Archived means fork-or-inline. The package is roughly one context class plus glue. If your constraints don't resolve cleanly, copy the class into your bootstrap, keep the attribution, and move on. Vendoring an archived dependency to save ~80 lines is a bad trade.

The test env must have a live Doctrine connection. Fixtures persist through the real entity manager against your test database. A missing or stale schema is the number-one failure mode; run bin/console doctrine:schema:create --env=test (or your migration flow) before blaming the extension.

Purging order beats transaction rollback here. Wrapping scenarios in a rolled-back transaction breaks as soon as a step triggers a redirect or an HTTP kernel sub-request that opens its own connection. Purge explicitly and accept the slower cleanup; if you must roll back, keep every step inside one process.

Faker is random — seed it. Non-deterministic fixture data turns a 1-in-50 failure into an unreproducible mystery. Seed the generator in a bootstrap hook, and when a scenario does fail, log the seed so it can be replayed.

Unique constraints and Faker collide. <email()> can repeat across large fixture sets, and any unique index surfaces that as an opaque ConstraintViolationException with no reference to the fixture line. Use <unique()->email()> or index-suffixed templates.

Alice references are per-load. @user_alice only resolves within a single loadFiles/loadFixtures call. Splitting related fixtures across two calls silently gives you two Alices. Load a file and its dependencies together, or let the bundle's loader resolve includes.

Debug by leaving Behat. When a fixture fails to parse, the stack trace is buried under Behat's formatter. Reproduce with bin/console hautelook_alice:doctrine:fixtures:load --env=test path/to/file.yml — the error messages are far better, and a success there isolates the problem to the Behat wiring.

Extension points live in the bundle, not the extension. Custom Faker providers (faker.provider tag), Alice ProcessorInterface implementations for post-load tweaking, and alternate persisters are all hautelook/alice-bundle features. Don't go looking for them in this package — it does not wrap them.

Treat low adoption as a documentation tax. With 36 stars and 0 dependents, there is no blog-post trail to fall back on. Write a short docs/testing.md in your own repo the day you add this: which context trait you used, which fixture directory is canonical, and how to seed Faker. Your future self is the only maintainer of that knowledge.