Оптимальный способ подгрузки фикстур в Symfony + phpunit + codeception?

Question

[HellWalk]

Вариант подгрузки фикстур из документации симфони следующий:

php bin/console doctrine:fixtures:load

Но выполнять эту команду каждый раз, перед выполнением тестов - такое себе.

Можно подгрузить фикстуры в самом тесте:

$fixtures = new ProductFixtures();
$fixtures->load($this->entityManager);

И запихнуть это куда-нибудь... в setUp().

Но, и такой вариант мне кажется не наилучшим. Нет более оптимального способа?

Например как-нибудь через аннотации:

/**
     * @fixture ProductFixture
     * @dataProvider invalidDateProvider
     * @param string $dateFrom
     * @param string $dateTo
     * @throws ApiException
     */
    public function testInvalidDate(string $dateFrom, string $dateTo): void

?

Comments

[BoShurik]

Может быть интересно: https://github.com/zenstruck/foundry

Answer 1

[Dmitry]

Через аннотации будет не лучшим вариантом, потому что нужно передавать или ObjectManager, или Client, с помощью которого потом получать необходимые объекты.

Можно сделать trait, который затем использовать в классе теста.

declare(strict_types=1);

namespace App\Tests\Common;

use Doctrine\Common\DataFixtures\Executor\ORMExecutor;
use Doctrine\Common\DataFixtures\FixtureInterface;
use Doctrine\Common\DataFixtures\Loader;
use Symfony\Bundle\FrameworkBundle\Client;

trait LoadFixturesTrait
{
    public static function loadFixtures(Client $client, array $fixtures, bool $append=false)
    {
        $fixturesLoader = $client->getContainer()->get(Loader::class);
        $fixturesExecutor = $client->getContainer()->get(ORMExecutor::class);

        foreach ($fixtures as $fixture) {
            $fixturesLoader->addFixture(
                $client->getContainer()->get($fixture)
            );
        }

        $fixturesExecutor->execute($fixturesLoader->getFixtures(), $append);
    }
}

И в классе теста:

use LoadFixturesTrait;
...
protected function setUp()
{
	SomeTest::loadFixtures(static::createClient(), [ProductsFixture::class]);
}

В массиве передается список фикстур, которые нужно применить.

В случае, если в методе теста используется экземпляр класса Symfony\Bundle\FrameworkBundle\Client, то именно этот объект нужно передавать в вышеуказанный метод.

Comments

[HellWalk]

Интересный вариант, надо попробовать.

В приемочных тестах у нас фикстуры одной строчкой подгружаются (что удобно), ваш вариант похож по использованию.

Как попробую и заработает - отмечу решением.

[HellWalk]

Вы упомянули класс
use Doctrine\Common\DataFixtures\Loader;

Можете показать его содержимое?

[Dmitry]

HellWalk, https://github.com/doctrine/data-fixtures/blob/1.4...

Он входит в пакет doctrine/data-fixtures, который является зависимостью для DoctrineFixturesBundle

Answer 2

[bkosun]

Можно использовать Makefile, чтобы автоматизировать рабочий процесс

Makefile:

SHELL := /bin/bash

tests:
	symfony console doctrine:fixtures:load -n
	symfony php bin/phpunit
.PHONY: tests

https://github.com/the-fast-track/book-5.0-4/blob/...

Чтобы сбрасывать базу данных после каждого теста, используйте DoctrineTestBundle:

$ symfony composer require dama/doctrine-test-bundle --dev

phpunit.xml

...
    <extensions>
        <extension class="DAMA\DoctrineTestBundle\PHPUnit\PHPUnitExtension" />
    </extensions>
...

https://github.com/the-fast-track/book-5.0-4/blob/...

Каждый раз, когда Вы хотите выполнить тесты, используйте команду make tests:

$ make tests

https://symfony.com/doc/current/the-fast-track/ru/...

Comments

[HellWalk]

Можно использовать Makefile, чтобы автоматизировать рабочий процесс

Если процесс можно автоматизировать без дополнительных свистелок (просто парой десятков дополнительных строк кода) - лучше делать без них

Чтобы сбрасывать базу данных после каждого теста, используйте DoctrineTestBundle

Во первых, такой функционал уже есть в codeception, и не нужны никакие дополнительные бандлы
Во вторых, подход, когда после каждого теста перезаписывается база плох тем, что очень сильно замедляется выполнение тестов. Лучше обновлять базу один раз, при запуске тестов.

А еще лучше, как сделано у меня в пет-проекте, когда фикстуры накатываются в autocommit mode-off (и rollback после каждого теста) - жесткий диск в этом случае вообще не задействуется, и все манипуляции с базой происходят мгновенно.

[bkosun]

Если процесс можно автоматизировать без дополнительных свистелок (просто парой десятков дополнительных строк кода) - лучше делать без них

Hard coding?

Во вторых, подход, когда после каждого теста перезаписывается база плох тем, что очень сильно замедляется выполнение тестов.

doctrine-test-bundle

With the help of a PHPUnit listener class it will begin a transaction before every testcase and roll it back again after the test finished for all configured DBAL connections. This results in a performance boost as there is no need to rebuild the schema, import a backup SQL dump or re-insert fixtures before every testcase. As long as you avoid issuing DDL queries that might result in implicit transaction commits (Like ALTER TABLE, DROP TABLE etc; see https://wiki.postgresql.org/wiki/Transactional_DDL...) your tests will be isolated and all see the same database state.

https://github.com/dmaicher/doctrine-test-bundle

О какой перезаписи идет речь?

Лучше обновлять базу один раз, при запуске тестов...

https://symfony.com/doc/current/the-fast-track/ru/...