php-test-fixture-loading is a package which tries to ease in the process of loading testing fixtures to have a better maintainability and code reuse. With this package, (data) fixtures can be created as simple classes that can be joined to compose more complex testing scenarios.
composer require --dev golossus/php-test-fixture-loading
Use the trait FixtureLoaderTrait on a base test class or TestCase
. Those will typically inherit from a PHPUnit
test class, like the Symfony WebTestCase
or similar.
Additionally, this trait has an abstract method buildFixture
which should be implemented as well. This method is
responsible to adapt the way data fixtures are instantiated, because different projects might follow different
approaches. This is specially true when a Dependency Injection container is needed to build a fixture.
As an example take the following TestCase
class which uses a Symfony 4 WebTestCase
. Take a look at the trait and
the method:
<?php declare(strict_types = 1);
namespace App\Tests\Rest;
use Golossus\TestFixtureLoading\Fixture;
use Golossus\TestFixtureLoading\FixtureLoaderTrait;
use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
class FunctionalTestCase extends WebTestCase
{
use FixtureLoaderTrait;
protected function buildFixture(string $namespace): Fixture
{
return self::$container->get($namespace);
}
}
Your case might be more complex (or maybe simpler), so implement this method to cover your needs.
For Symfony applications like in the example above don't forget to declare the fixtures folder as services, or you won't be able to build the fixtures.
Although the example uses the testing container to build the data fixtures, so in practice you're allowed to build private services (which is the default behaviour), actually it's possible that you need to make the fixtures public. Look at the following example:
# in cofig/services_test.yaml
services:
_defaults:
autowire: true
autoconfigure: true
App\Tests\DataFixtures\:
resource: '../tests/DataFixtures/*'
public: true
To create a fixture is so easy as creating a new class which implement the Fixture interface. This interface only
provides two methods: load
and depends
. The first one defines the logic to create the data and provides
a FixtureRepository parameter to store a reference on memory of any object created (and maybe stored in the
database) which can be retrieved afterwards on the test function. The second method is useful to define which other data
fixtures should be loaded before the current one.
All dependencies of a loaded fixture will be also loaded even if they are not specified directly in the list of fixtures to load.
If any fixture declares a dependency graph which produces a cycle, will throw an exception during the loading phase.
Even if some dependency is used more than once it will actually load just one time.
As an example of fixture:
<?php declare(strict_types = 1);
namespace Tests\Fixtures;
use Golossus\TestFixtureLoading\AbstractFixture;
use Golossus\TestFixtureLoading\FixtureRepository;
...
class AdminUserFixture extends AbstractFixture
{
...
const ADMIN_USER = 'admin-user';
public function load(FixtureRepository $fixtureRepository): void
{
$company = $fixtureRepository->get(CompanyFixture::COMPANY);
$user = $this->createAdminUserForCompany($company);
$fixtureRepository->set(self::ADMIN_USER, $user);
}
public function depends(): array
{
return [
CompanyFixture::class,
];
}
}
Once the configuration above has been completed, the usage is quite straightforward, just use the method loadFixtures
provided in the previous trait to load any desired fixture. This method returns a special fixture repository which is
used during loading to store object references on demand.
public function testWhateverYouLike()
{
// First load the required data fixtures
$fixtures = $this->loadFixtures([
SomeDataFixture::class,
AnotherDataFixture::class,
]);
// You can get a data fixture object by key
$dummy = $fixtures->get('some-key');
// The rest should be a normal test
}
- Join our Slack to meet the community and get support.
- Follow us on GitHub.
- Read our Code of Conduct.
This is an Open Source project. The Golossus team wants to enable it to be community-driven and open to contributors. Take a look at contributing documentation.
If you discover a security vulnerability, please follow our disclosure procedure.
This package development is led by the Golossus Team Leaders and supported by contributors.