Yaml Fixtures Bundle Laravel Package

Getting Started

This bundle is a Symfony 2.x integration that lets Doctrine fixtures live in YAML files instead of PHP classes. It is archived and unmaintained, so treat it as something you adopt only on an existing Symfony2/Doctrine2 codebase — pin the version in composer.json and never let a composer update float it.

Minimal setup:

1. Install with the fixtures groundwork it expects:

   composer require --dev doctrine/doctrine-fixtures-bundle
   composer require --dev khepin/yaml-fixtures-bundle
   

2. Register the bundle in app/AppKernel.php (dev/test only):

   if (in_array($this->getEnvironment(), ['dev', 'test'])) {
       $bundles[] = new Doctrine\Bundle\FixturesBundle\DoctrineFixturesBundle();
       $bundles[] = new Khepin\YamlFixturesBundle\KhepinYamlFixturesBundle();
   }
   

3. Point it at a directory of YAML files in app/config/config.yml:

   khepin_yaml_fixtures:
       fixtures_dir: "%kernel.root_dir%/../src/Acme/DemoBundle/Resources/fixtures"
   

4. Drop in a file and load it:

   # fixtures/01-users.yml
   Acme\DemoBundle\Entity\User:
     user_admin:
       username: admin
       email: [email protected]
       roles: [ROLE_ADMIN]
   

   php app/console doctrine:fixtures:load --env=dev
   

Look first at the bundle's loader class (under Khepin\YamlFixturesBundle\Loader) — that is where file ordering and the @reference resolution happen, and it explains almost every surprising behaviour you will hit. First real use case: seeding roles, an admin user, and a handful of reference/lookup rows so a fresh doctrine:schema:create gives you a login-able dev database in one command.

Implementation Patterns

One file per entity, numeric prefixes for load order. Because references resolve against previously loaded fixtures, file order is your dependency graph. 01-users.yml, 02-posts.yml, 03-comments.yml is the idiomatic layout; relying on alphabetical accident is a maintenance trap.

References via @fixture_name. Within a YAML file, a fixture key is the handle; from other files and other entities you point at it:

Acme\DemoBundle\Entity\Post:
  post_welcome:
    title: "Welcome"
    author: "@user_admin"      # quoted — see gotchas
    tags: ["@tag_news", "@tag_php"]

Use references for owning-side associations and let Doctrine persist the graph; you rarely need to set inverse collections explicitly.

Treat fixture names as your test API. Name fixtures semantically (user_admin, user_buyer) rather than user_1, and in functional tests fetch them by the identifying column you set. This is the single biggest day-to-day payoff: tests become "load the fixture set, look up user_buyer" instead of building object graphs in setUp().

Separate dev and test fixture directories by making the config value a parameter and overriding it in config_test.yml:

# config_test.yml
parameters:
    fixtures_dir: "%kernel.root_dir%/../src/Acme/DemoBundle/Resources/fixtures/test"

Mix with PHP fixtures when you need logic. YAML is for static graph data; computed values (password hashes, random tokens, dates relative to now) belong in a small PHP fixture class that runs after the YAML load, or in a base test case that loads YAML then patches fields. Avoid the temptation to encode logic in YAML — there is none.

Use --append / --no-purge deliberately. Purging wipes the whole schema in FK order; on large dev databases that's slow. --append is fine for additive lookup data but will duplicate rows on re-run unless your fixture names map to unique constraints.

Gotchas and Tips

• YAML reserved indicators will bite you. A scalar starting with @ is not valid YAML — author: @user_admin fails to parse or silently becomes an odd string. Always quote references: author: "@user_admin". Same for leading %, *, &, and unquoted values like yes, no, on, null, 2017-07-26 (parsed as a date, not a string), and 0123 (octal/leading-zero).
• No forward references. A fixture can only reference something already loaded. If you get "reference not found," it is almost always file ordering, not a typo — renumber the file.
• Constructor arguments and private setters are out of reach. The loader populates via property access/setters; entities requiring constructor args, value objects, or final immutable properties need a PHP fixture or a factory.
• Archived and Symfony2-only. Service definitions, AppKernel registration, and the app/console binary all assume Symfony 2. It does not fit Symfony 4+/Flex autowiring, and no one is fixing bugs. Budget for migrating to nelmio/alice + hautelook/alice-bundle (or plain PHP fixtures) if the project moves forward.
• FK constraints during purge. Purging deletes tables in the order Doctrine knows about; circular or un-mapped associations cause failures. Fix the mapping first, and check --no-purge as a workaround while diagnosing.
• Memory on bulk loads. The loader holds reference objects for the whole run. For thousands of rows, load in batches or call $em->clear() in an accompanying PHP fixture — just remember clearing detaches the objects your references point at.
• Debugging tips. When a fixture "loads" but fields are empty, dump the parsed array (Yaml::parse(file_get_contents(...))) to confirm YAML coercion isn't the culprit; run with -v to see which files the command actually picked up; and verify fixtures_dir resolves (it is a raw path string, so a trailing slash or a wrong %kernel.root_dir% silently yields zero fixtures rather than an error).
• Extension point: the loader is a service, so you can override or decorate it to add conventions — e.g. auto-hashing a password key, injecting a created_at, or supporting a custom __factory directive — without forking the bundle.