Фикстуры

Больше 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 $backupGlobalsExcludeList = ['globalVariable'];

    // ...
}

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

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

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

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

    // ...
}