Download the PHP package silvertipsoftware/fixtures without Composer

Fixtures

A relatively faithful clone of ActiveRecord's fixture capability. Much of the docs from there are relevant, but some of the key points are below.

Fixtures are an easy way of setting up a test database to a known point, rather than continuously creating objects via factories in every test. The are not meant to create everything you'd ever need in a test, just the basics to form a reasonable starting point.

Fixtures are written in YAML, and there's one file per Eloquent model class.

Requirements & Caveats

• Tests must use DatabaseTransactions, since the fixtures are created before the tests run, and need to be returned to the known-good state after each test. This may change in future releases.
• Namespaced Eloquent models are not handled particularly well, although the model_class directive goes a long way.
• YAML files are not pre-processed, so no PHP or Blade templating is possible. This will definitely change soon, as it makes user password creation a chore.
• All fixtures that are defined will wipe their model's table. DO NOT run tests against data you care about.

Basic Usage

Fixtures by default live in the tests/fixtures directory, although that is configurable via the $fixturePath. Fixture file names and model names typically match, so to create a fixture for an \App\Framework model, create test/fixtures/frameworks.yml like:

When your tests run, these 3 database records will be created, and ids automatically assigned when needed. Accessor macros are also created, so referencing a fixture in a test is as easy as:

Relations

Relations that are instances of BelongsTo and BelongsToMany, which includes the morphing MorphTo and MorphToMany, can also be easily set up by name. Polymorphic relations must include the morph type (the classname by default, or whatever is in your morphMap) in parentheses. Fixtures sets the id (and type for polymorphisms) of the relation automatically, so you don't have to juggle manual ids.

Class Names

As mentioned above, namespaced models are not handled well yet. Fixtures defaults to using the default Laravel namespace of \App, but if you put models elsewhere you'll have to tell Fixtures what model class the fixture set is for.

In your YAML include a record like:

If the bulk of your models live in one namespace, you can change the default by setting $modelNamespace in your test class. So, we could eliminate the need for the above by:

Fixtures outside this namepsace will need model_class records. And this does not affect the string used for polymorphic relations.

Label Interpolation & Defaults

Including the string $LABEL in a column definition will replace that tag with the label of the fixture, which is often great for usernames, email addresses, etc:

For repetitive records like the above, a special DEFAULTS row can be specified using YAML anchors, so a longer user fixture set or a model with many fields to set could look like:

Label interpolation is done after default replacement, so this will generate users with the usernames mary, barb, etc.