PHPackages                             flyos/factory-girl-php - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Testing & Quality](/categories/testing)
4. /
5. flyos/factory-girl-php

AbandonedArchivedLibrary[Testing & Quality](/categories/testing)

flyos/factory-girl-php
======================

Fixture replacement for focused and readable tests - A PHP port of Thoughtbot's Ruby Factory Girl

01.0k[1 PRs](https://github.com/FlYos/factory-girl-php/pulls)PHP

Since Dec 19Pushed 4y ago1 watchersCompare

[ Source](https://github.com/FlYos/factory-girl-php)[ Packagist](https://packagist.org/packages/flyos/factory-girl-php)[ RSS](/packages/flyos-factory-girl-php/feed)WikiDiscussions master Synced 4w ago

READMEChangelogDependenciesVersions (2)Used By (0)

Factory Girl in PHP
===================

[](#factory-girl-in-php)

[![Build Status](https://camo.githubusercontent.com/57e960af25e17a453ea4a5e800e943a21e0b742feb6096a3f4ef6c52e6344517/68747470733a2f2f7365637572652e7472617669732d63692e6f72672f466c596f732f666163746f72792d6769726c2d7068702e706e673f6272616e63683d6d6173746572)](http://travis-ci.org/FlYos/factory-girl-php)

A PHP port of Thoughtbot's Ruby [Factory Girl](https://github.com/thoughtbot/factory_girl). Based on a fork of [breerly/factory-girl-php](https://github.com/breerly/factory-girl-php).

FactoryGirl FixtureFactory
--------------------------

[](#factorygirl-fixturefactory)

`FactoryGirl\Provider\Doctrine\FixtureFactory` provides convenient creation of Doctrine entities in tests. If you're familiar with [FactoryGirl](https://github.com/thoughtbot/factory_girl) for Ruby, then this is essentially the same thing for Doctrine/PHP.

### Motivation

[](#motivation)

Many web applications have non-trivial database structures with lots of dependencies between tables. A component of such an application might deal with entities from only one or two tables, but the entities may depend on a complex entity graph to be useful or pass validation.

For instance, a `User` may be a member of a `Group`, which is part of an `Organization`, which in turn depends on five different tables describing who-knows-what about the organization. You are writing a component that change's the user's password and are currently uninterested in groups, organizations and their dependencies. How do you set up your test?

1. Do you create all dependencies for `Organization` and `Group` to get a valid `User` in your `setUp()`? No, that would be horribly tedious and verbose.
2. Do you make a shared fixture for all your tests that includes an example organization with satisifed dependencies? No, that would make the fixture extremely fragile.
3. Do you use mock objects? Sure, where practical. In many cases, however, the code you're testing interacts with the entities in such a complex way that mocking them sufficiently is impractical.

`FixtureFactory` is a middle ground between *(1)* and *(2)*. You specify how to generate your entities and their dependencies in one central place but explicitly create them in your tests, overriding only the fields you want.

### Tutorial

[](#tutorial)

We'll assume you have a base class for your tests that arranges a fresh `EntityManager` connected to a minimally initialized blank test database. A simple factory setup looks like this.

```