Download the PHP package globalprofessionalsearch/popov without Composer

Popov

Plain Old Php Object Factory

This is a library for generating object graphs in PHP. It's primarily used in conjunction with other libraries to generate data fixtures. It does not include facilities for persisting data to a database; it's up to the user to determine the best method for doing so.

Why write this?

Many fixture libraries available make assumptions about the underlying storage mechanism, or are fairly complicated. For some tests it may be enough to have access to objects that would have been fetched from the data store, without needing to involve that layer in the actual test. But in an integration test you do want the database layer involved. Popov lets you define your fixture models in a way that is relatively simple, but still useful in multiple contexts. By not making assumptions about persistence, you are free to integrate this into your applications in whatever manner is the most suitable, and maintain full control.

Installation

Add it to your project's composer.json:

Usage

Below are usage examples, starting with the simplest, and increasing in complexity. Since a fixture definition often requires the use of closures, and since Faker is so widely used for generating data points, we highly recommend using the league/factory-muffin-faker library in conjunction with Popov. Most of the examples below use it, and you'll see that the use of facades greatly reduces the need to manually wrap field definitions in closures.

The examples below show defining pools of fictional classes that may be in an application. It's assumed that these classes exist and provide getters/setters for the attributes described. This is not a requirement - Popov will use reflection to set any public/protected/private properties defined.

Each example below adds to the previous one.

Defining Pools

Let's assume we have users and groups, and we need to generate fake instances of each. The example below defines two pools of objects with a preset number of instances in each. When you define a pool, you provide the fully qualified class name (FQCN) to be used when creating the objects, and an option number of instances to be created when the pool is initialized. Here we will define pools that generate 100 users and 20 groups:

The first time an object is retrieved from the factory, the factory will initialize all defined pools in the order in which they were defined.

You can also define pools with an alias. Doing this lets you avoid having to use the FQCN to reference the pool, but it also gives you the option of creating more than one pool for the same class if you need them to be configured differently.

Retrieving Objects

Once you have defined pools you can fetch created objects by using the api exposed by the GPS\Popov\Pool. You can either fetch the pool directly from the factory, or use the wrapper methods provided by the factory.

The pools provide a few ways to fetch objects:

Nesting

To add to the example above, lets say that users also have account preferences, which is a nested object. Any time a user is created, a nested object to hold their preferences should also be created. We'll update the user definition above, and add a new one:

References

Nested objects are fairly straight forward, but sometimes you need objects from another pool, and you shouldn't trigger creating new ones. For example, suppose we want all of our users to be in a group, but we don't want to create a new group for every user. To do this, we use the factory to add a reference. A reference is really the same thing as an attribute, but the factory resolves it after all pools have been initialized. This allows you to fetch reference objects from other pools, including circular dependencies, without risking infinite loops.

To add a reference to an object in another pool, we'll just use the factory facade to wrap the action in a closure:

Hooks

Popov also provides a way to call a callback after each object has been created, and also after an entire pool has been initialized.

Hard-coded objects

You may want 50 random objects in a pool, but you may also want a few objects that you can reference in tests which are defined explicitly by you, so you know up front what to expect. If you have defined a pool, you can manually create new instances regardless of whether or not it will be automatically populated with a preset number. Any manually created instances will just be added to the pool.

This has an important implication though - if you want to create a few explicit objects, you should do that after you have defined all of your pools. Manual creation of an object will trigger initialization of all defined pools.

You can create a specific object by overriding the definition at create time:

Example with Persistence

Dealing with persistence can be fairly strait forward if you know the requirements for your app. While Popov doesn't provide this out of the box, below is a simple example for how it could be done in an app that uses Doctrine.

Contributing

Contributions are certainly welcome - just please adhere to the [PSR] coding standards.

Testing

Run the tests with vendor/bin/phpunit.