Фикстуры

Более setUp() чем tearDown()

setUp() и tearDown() теоретически симметричны, но на практике нет. На практике вам нужно реализовать только tearDown(), если вы выделили внешние ресурсы, такие как файлы или сокеты, в setUp(). Если ваша setUp() просто создаёт обычные объекты PHP, вы, как правило, можете игнорировать tearDown(). Однако, если вы создаёте множество объектов в вашей setUp(), вы можете захотеть unset() переменные, указывающие на эти объекты, в вашей tearDown(), чтобы они могли быть удалены сборщиком мусора. Удаление сборщиком мусора объектов класса тестирования непредсказуемо.

Варианты

Что происходит, когда у вас есть два теста с немного отличающимися настройками? Существует два варианта:

• Если код setUp() отличается незначительно, перенесите код, отличающийся от кода setUp() в метод теста.
• Если у вас действительно другая setUp(), вам нужен другой класс теста. Назовите класс в соответствии с отличием в настройке.

Разделяемая фикстура

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

Хороший пример фикстуры, которую имеет смысл разделять между несколькими тестами, — это подключение к базе данных: вы подключаетесь к базе данных один раз и повторно используете соединение, вместо создания нового соединения для каждого теста. Это ускоряет выполнение ваших тестов.

Пример 4.3 использует шаблонные методы setUpBeforeClass() и tearDownAfterClass() для подключения к базе данных перед первым тестом класса тестирования и для отключения от базы данных после последнего теста класса тестирования соответственно.

<?php declare(strict_types=1);
use PHPUnit\Framework\TestCase;

final class DatabaseTest extends TestCase
{
    private static $dbh;

    public static function setUpBeforeClass(): void
    {
        self::$dbh = new PDO('sqlite::memory:');
    }

    public static function tearDownAfterClass(): void
    {
        self::$dbh = null;
    }
}

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

Глобальное состояние

Сложно тестировать код, использующий синглтоны. То же самое верно и для кода, использующего глобальные переменные. Обычно код, который вы хотите протестировать, сильно связан с глобальной переменной, и вы не можете контролировать ее создание. Дополнительная проблема заключается в том, что изменения одной проверки в глобальной переменной могут сломать другую проверку.

В PHP глобальные переменные работают так:

• Глобальная переменная $foo = 'bar'; хранится как $GLOBALS['foo'] = 'bar';.
• Переменная $GLOBALS — это так называемая суперглобальная переменная.
• Суперглобальные переменные — это встроенные переменные, которые всегда доступны во всех областях видимости.
• В области видимости функции или метода вы можете получить доступ к глобальной переменной $foo, либо напрямую обратившись к $GLOBALS['foo'], либо используя global $foo;, чтобы создать локальную переменную со ссылкой на глобальную переменную.

Помимо глобальных переменных, статические атрибуты классов также являются частью глобального состояния.

До версии 6 по умолчанию PHPUnit запускал ваши тесты таким образом, что изменения глобальных и суперглобальных переменных ($GLOBALS, $_ENV, $_POST, $_GET, $_COOKIE, $_SERVER, $_FILES, $_REQUEST ) не влияли на другие тесты.

Начиная с версии 6, PHPUnit больше не выполняет эту операцию резервного копирования и восстановления для глобальных и суперглобальных переменных по умолчанию. Она может быть активирована с помощью параметра --globals-backup или установки backupGlobals="true" в файле конфигурации XML.

Используя параметр --static-backup или устанавливая backupStaticAttributes="true" в файле конфигурации XML, это изолирование может быть расширено до статических атрибутов классов.

Аннотация @backupGlobals, о которой идет речь в @backupGlobals, может использоваться для управления операциями резервного копирования и восстановления для глобальных переменных. В качестве альтернативы, вы можете предоставить список глобальных переменных, которые следует исключить из операций резервного копирования и восстановления, например так

final class MyTest extends TestCase
{
    protected $backupGlobalsBlacklist = ['globalVariable'];

    // ...
}

Аннотация @backupStaticAttributes, обсуждаемая в @backupStaticAttributes, может использоваться для резервного копирования всех значений статических свойств во всех объявленных классах перед каждым тестом и восстановления их после.

Обрабатываются все классы, объявленные в момент запуска теста, а не только сам класс теста. Она применяется только к статическим свойствам класса, а не к статическим переменным внутри функций.

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

final class MyTest extends TestCase
{
    protected $backupStaticAttributesBlacklist = [
        'className' => ['attributeName']
    ];

    // ...
}