Laravel Fixtures Laravel Package

Getting Started

manageitwa/laravel-fixtures is a fixture-loading package for Laravel that lets you define reusable data sets and load them into the database (typically in tests or seeders). As of v1.4.0 it supports Laravel 11 and 12, so it drops cleanly into modern apps.

Where to look first:

1. composer.json / package README — confirm the PSR-4 namespace and the config key. Fixture packages almost always ship a config/fixtures.php you can publish.
2. Publish the config if the package exposes one:

   php artisan vendor:publish --tag=fixtures-config
   

3. Locate the fixture directory convention. Most packages look in tests/Fixtures, database/fixtures, or a path set in config. Match the package default before pointing it elsewhere.
4. Run the test suite to confirm the package autoloads and resolves its service provider on Laravel 11/12 (the main thing this release changes).

First use case — seed a single representative record set in a feature test:

use ManageItWA\Fixtures\Facades\Fixtures; // verify exact namespace in README

public function test_orders_index(): void
{
    Fixtures::load('orders');

    $this->get('/orders')->assertOk();
}

If the package uses PHP fixture files, define your first fixture in the conventional path and inspect the returned records/count to confirm it loaded. Start with one fixture, verify it against a RefreshDatabase test, then expand.

Implementation Patterns

Test isolation. Pair fixtures with RefreshDatabase (or DatabaseTransactions) so each test starts from a clean slate. Fixtures loaded once at class setup will leak between tests otherwise.

Fixture-per-scenario. Structure fixture files by intent (orders_empty, orders_with_refunds, users_admin) rather than by table. Loading a scenario is easier to reason about than composing table-level dumps.

Seeding in production/local. If the package supports it, reuse fixtures for local dev seeding through a seeder that calls the loader, so test data and dev data stay in sync. Guard this so it never runs against production.

Composition over mega-fixtures. Prefer loading several small fixtures in a setup method rather than one giant file. Keep relationships explicit (parents before children) unless the package handles dependency ordering.

CI integration. Add fixture loading to your test bootstrap or a base TestCase::setUp() so developers don't wire it per-test. On Laravel 11/12 (slim skeleton), confirm the tests/TestCase.php still boots the app correctly.

Version-aware install. In composer.json, require ^1.4 and let it resolve against Laravel 11 or 12. If you support both 10 and 11/12, verify the older line still installs — v1.4.0 signals current support, not necessarily a hard break with 10.

Gotchas and Tips

• Laravel 11/12 skeleton differences. The slim app skeleton moved config files and changed the bootstrap. If you previously copied config into config/, confirm the service provider still registers and the config is merged (fallback) correctly rather than only read from a published file.
• Autoloading fixture files. Fixture files outside tests/ may not be autoloaded or may be excluded by phpunit.xml <source>/<coverage> settings. Check .gitattributes export-ignore and composer autoload if fixtures "disappear" in CI.
• Transaction vs. truncation. If the package truncates tables, it can fight RefreshDatabase's transaction wrapping. Pick one strategy; mixing them produces confusing "data already exists" errors.
• Foreign keys. Disable FK checks only if the package does it for you. Loading child fixtures before parents silently fails or throws constraint errors depending on the DB driver (SQLite is stricter than MySQL here).
• Cache and config caching. Run php artisan config:clear after changing fixture paths. In CI, a stale bootstrap/cache/config.php is a common reason fixtures look in the wrong directory.
• Extensions. Use the package's events/hooks (if exposed) or wrap the loader in your own base test trait to add logging, timing, or per-test fixture tracking.
• Debugging loads. If a fixture appears not to load, dump the resolved path and the record count immediately after the call; most issues are path/config resolution, not the fixture content.
• Version pinning. Because v1.4.0 is the first release claiming Laravel 11/12 support, pin ^1.4 in production rather than a floating constraint, and smoke-test the upgrade against your existing fixtures before rolling out.