Download the PHP package adamwathan/faktory without Composer
On this page you can find all versions of the php package adamwathan/faktory. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download adamwathan/faktory
More information about adamwathan/faktory
Files in adamwathan/faktory
Package faktory
Short Description An attempt at bringing the wonders of Ruby's FactoryGirl to PHP
License MIT
Informations about the package faktory
Important: This package is not actively maintained. For bug fixes and new features, please fork.
Faktory
Faktory is a tool for easily building test objects ala FactoryGirl, but for PHP. It's still in it's early stages, but give it a go if you're interested, and open issues for the features it's missing that you think are really important.
Installing with Composer
You can install this package via Composer on the command line from your project's root:
Laravel 4
If you are using Laravel 4, you can get started very quickly by registering the included service provider.
Modify the providers
array in app/config/app.php
to include the FaktoryServiceProvider
:
Add the Faktory
facade to the aliases
array in app/config/app.php
:
You can now start using Faktory by calling methods directly on the Faktory
facade:
Outside of Laravel 4
To use outside of Laravel 4, just instantiate a new Faktory
. Make sure you register this as a singleton in your favorite dependency injection container, since you probably want to be using the same instance everywhere.
Note: When using outside of Laravel 4 and not having access to the
Faktory
facade, you will need to make sure youuse
your$faktory
instance in any nested closures that need to generate other objects. Sucks but that's PHP.
Using Faktory
Defining factories
Define factories anywhere you want.
In Laravel 4, I've been creating a factories.php
file in my tests directory and adding it to app/bootstrap/testing.php
like so:
Basic definition
The most basic factory definition requires a class name and a closure that defines the default attributes for the factory. This will define a factory named after that class that generates instances of that same class.
Using factories
Once you have your factories defined, you can very easily generate objects for your tests.
Objects can be generated using one of two different build strategies.
build
creates objects in memory only, without persisting them.create
creates objects and persists them to whatever database you have set up in your testing environment.
Note: The
create
strategy is meant for Laravel 4's Eloquent ORM, but as long as your objects implement asave()
method and agetKey()
method to retrieve the object's ID, it should work outside of Eloquent.
To generate an object, simply call build
or create
and pass in the name of the factory you want to generate the object from.
Overriding attributes
The real benefit of using these factories appears when you are writing a test that requires your objects to satisfy some precondition, but you don't really care about the rest of the attributes.
You can specify the values you need for the attributes that matter for the test, and let the factory handle filling out the attributes you don't care about with default data so that the object is in a valid state.
If you just need to change some simple attributes to static values, you can just pass an array of attribute overrides as a second argument:
If you need to do something trickier, you can pass in a closure that provides all of the same functionality you get when actually defining the factory. This is most useful when working with relationships:
Named factories
Factories can also be given a name, so that you can define multiple factories for the same class that generate objects in different predefined states.
To define a named factory, pass the name as the second parameter, and move the callback to the third parameter.
Factory inheritance
You can create factories that inherit the attributes of an existing factory by nesting the definition. This allows you to define a basic factory, as well as more specific factories underneath it to generate objects in a specific state without having to redeclare the attributes that don't need to change.
Lazy attributes
If you don't want an attribute to be evaluated until you try to build an object, you can define that attribute as a closure.
Dependent attributes
You can also use lazy attributes to define attributes that depend on other attributes in the factory.
Unique attributes
Lazy attributes to the rescue again. The closure also takes an autoincrementing integer as it's second parameter, which is really handy for ensuring that a field value is unique.
Defining relationships
Faktory lets you easily define relationships between objects.
Currently, there is support for belongsTo
, hasOne
, and hasMany
relationships.
Belongs to
Define a belongsTo
relationship by assigning a belongsTo
call to an attribute.
belongsTo()
takes the name of the factory that should be used to generate the related object as the first argument, the name of the foreign key column as the second argument, and an optional array of override attributes as the third argument.
Has one
Define a hasOne
relationship by assigning a hasOne
call to an attribute.
hasOne()
takes the name of the factory that should be used to generate the related object as the first argument, the name of the foreign key column (on the related object) as the second argument, and an optional array of override attributes as the third argument.
Has many
Define a hasMany
relationship by assigning a hasMany
call to an attribute.
hasMany()
takes the name of the factory that should be used to generate the related objects as the first argument, the number of objects to generate as the second argument, the name of the foreign key column (on the related object) as the third argument, and an optional array of override attributes as the final argument.
Relationships and build strategies
Relationships are handled differently by each build strategy.
When using the build
strategy, the related object(s) will be available directly as a property on the base object.
When using the create
strategy, the related object(s) will be persisted to the database with the foreign key attribute set to match the ID of the base object, and nothing will actually be set on the actual attribute itself, allowing you to retrieve the related object through the methods you've actually defined in the base object's class.
Overriding relationship attributes
If you need to override attributes on a relationship when building or creating an object, you can do so by manipulating the actual relationship attribute itself.
Building multiple instances at once
You can use buildMany
and createMany
to generate multiple objects at once: