Fixture content

Fixture Content turns real Drupal content into reusable test data for automated browser tests, then imports it and removes it again cleanly, without disturbing any other content on the site.

Automated end-to-end tests (Playwright, Cypress, Behat) need predictable content to test against: a page with a known title, a user with a known role, an article with particular paragraphs. On a fresh install you can simply create that content. But many teams test on shared development and feature-branch sites that hold a copy of real content and can't be reinstalled between test runs. Fixture Content is built for that situation. You build the content you need in the normal Drupal editing interface, export it to YAML files in your codebase, and the module imports it before your tests run and deletes it afterwards.

It is a thin layer over the Default Content API that Drupal core added in 11.3. Core exports and imports the content; this module adds the lifecycle around it.

Features

• Export any content entity as a fixture (nodes, taxonomy terms, users, media, custom blocks, menu links), together with its paragraphs, media and files. Optionally follow other references too (related nodes, terms), with a depth limit, type exclusions and a --dry-run preview of what will be exported.
• Fixtures are forks, not moves. Exported entities get new UUIDs from a reserved namespace (by default 7e57f1c7-…). Your source content is never modified, and a fixture never collides with the real item it came from, even on a site copied from production.
• Safe cleanup. One command deletes every fixture, in dependency order: everything your fixture directory describes, plus anything in the database carrying the fixture prefix (which catches orphans). Editorial content is never touched.
• Idempotent import. Anything already present is skipped and nothing is ever duplicated, so you can run the import as often as you like. Translated path aliases are synced after import.
• Refresh from the database. Edit a fixture in the Drupal UI, then re-export it, either one fixture or all of them at once.
• No credentials in your repository. Password hashes are stripped on export. Fixture users get a password from an environment variable at import time, and the import fails loudly if the variable isn't set.
• Fixtures live wherever you want, for example next to your test specs. They don't need to be inside a module.
• Paragraphs support: entity_reference_revisions fields are exported as portable UUID references, so paragraphs are reconnected correctly on import.

Use cases include end-to-end test suites on shared dev or CI environments, feature-branch builds that need a consistent baseline of content, and visual regression testing against known pages.

Post-Installation

There is no configuration page, content type or permission to set up. Everything is done with Drush and settings.php.

1. Enable the commands for this environment, and optionally choose where fixtures are stored, in settings.local.php or an environment-specific settings file:
   

   // Commands refuse to run unless this is set. Never set it on production.
   $settings['fixture_content']['enabled'] = TRUE;
   // Where fixtures live, relative to the project root.
   $settings['fixture_content']['directory'] = 'tests/fixtures/content';
   // Environment variable holding the password for fixture users.
   $settings['fixture_content']['password_env'] = 'TEST_PASS';

2. Create the content you need in the normal Drupal UI, then export it:
   

   drush fixture-content:export node 123

3. Review the YAML files written to your fixture directory, and commit them.
4. Before your tests run, import the fixtures; afterwards, delete them:
   

   drush fixture-content:import
   drush fixture-content:delete -y

After editing a fixture's content in the UI, update its YAML with drush fixture-content:update <uuid>, or run it with no argument to update all fixtures.

In your tests, refer to fixtures by UUID or path alias, never by node ID: IDs change on every import.

Not for production. This module deletes content and sets user passwords. Enable it only on development and test environments, and keep it out of your production configuration, for example with $settings['config_exclude_modules'] = ['fixture_content'];.

Additional Requirements

• Drupal 11.3 or later. This module relies on core's Default Content API, which core marks as experimental, so a minor core release may occasionally require an update here.
• Drush 13 or later.

Recommended modules/libraries

• Paragraphs: fully supported. Paragraphs are exported and imported with their host entity.
• Pathauto: fixture aliases are preserved on import, so tests can visit fixtures by a stable path.
• A browser test framework such as Playwright. This module provides the content; your test framework provides the tests.

Similar projects

• Drupal core content:export (11.3+) exports content, with its dependencies, as YAML that core can import. Use it if you only need a one-way export and import, for example to ship content with a recipe. Fixture Content builds on it and adds forking, refresh from the database, and safe deletion.
• Default Content is the long-standing contrib module for shipping content inside modules. It has no namespaced cleanup, so it can't remove its content again without risk to other content.
• Content Fixtures defines fixtures in PHP code and purges all content before loading them, which suits fresh installs rather than shared sites with real content.
• Automated Testing Kit provides Playwright and Cypress test helpers for Drupal. It is complementary to this module rather than an alternative.

Supporting this Module

Originally developed for the GOV.WALES platform and supported by the Welsh Government. Bug reports, patches and merge requests are welcome in the issue queue.

Community Documentation

See the README for the full command reference and the fixture file format. Walkthroughs and an example Playwright setup will be linked here as they become available.