PHPackages                             breerly/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. breerly/factory-girl-php

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

breerly/factory-girl-php
========================

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

1.2.0(6y ago)111242.8k↓50%23[1 issues](https://github.com/breerly/factory-girl-php/issues)2MITPHPPHP ^7.1CI failing

Since Oct 2Pushed 6y ago4 watchersCompare

[ Source](https://github.com/breerly/factory-girl-php)[ Packagist](https://packagist.org/packages/breerly/factory-girl-php)[ RSS](/packages/breerly-factory-girl-php/feed)WikiDiscussions master Synced 1mo ago

READMEChangelog (10)Dependencies (6)Versions (11)Used By (2)

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

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

[![Continuous Integration](https://github.com/unhashable/factory-girl-php/workflows/Continuous%20Integration/badge.svg)](https://github.com/unhashable/factory-girl-php/actions)

A PHP port of Thoughtbot's Ruby [Factory Girl](https://github.com/thoughtbot/factory_girl). Based on a fork of [xi-doctrine](https://github.com/xi-project/xi-doctrine).

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.

```