Фикстуры в PHPUnit

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

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

Разновидности

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

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

Совместное использование фикстур

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

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

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

<?php
use PHPUnit\Framework\TestCase;

class DatabaseTest extends TestCase
{
    protected static $dbh;

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

    public static function tearDownAfterClass()
    {
        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, может использоваться для управления операциями резервного копирования и восстановления глобальных переменных. Кроме этого, вы можете предоставить чёрный список глобальных переменных, которые должны быть исключены при выполнении операций резервного копирования и восстановления, как показано ниже:

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

    // ...
}

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

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

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

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

    // ...
}