Тестирование PHP проектов на примере Symfony29.01.2023 09:47

Хочу описать свои наработки и устоявшиеся подходы к тестированию PHP проектов. Последние годы я работаю с Symfony и здесь будет достаточно моментов специфичных для этого фреймворка. Так же в этой статье термин функциональные тесты (functional) является синонимом End-to-End тестов. Статья рассчитана на разработчиков уже знакомых с PHPUnit и Symfony, структурой composer файла. Врочем, здесь есть и общеизвестные моменты, чтобы облегчить понимание тем, кто только начинает писать тесты. Статья призвана упорядочить знания и показать какие-то удобные подходы. Формат статьи не позволяет раскрыть все нюансы. Тем не менее, я постараюсь озвучить все основные моменты, применяемые в работе и которые лично мне помогают на практике. 

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

• Все best practice программирования в равной степени относятся и к коду тестов. С той лишь разницей, что размер метода может быть больше из-за подготовки mock-объектов и больши́х dataset-ов (дата-провайдеров).

• Классическая пирамида: много Unit, меньше Integration, совсем мало Functional / End-to-End тестов.

• Тестировать нужно результат, а не особенности реализации. Одна из фундаментальных задач тестов — поддержание стабильности работы приложения, т.е. их способность гарантировать правильную работу приложения после внесения изменений. При этом тесты не должны мешать разработке — они не должны быть слишком жёсткими и требовать изменения на каждый чих.

• Минимизация скоупа проверки одним тестом (некая вариация single responsibility).

• 100% code coverage не равно 100% проверки работы приложения.

• Не писать фейковые тесты.

Окружение

Начнём с подготовки окружения. 

Первым делом договоримся, что тесты у нас будут лежать в папке tests в корне проекта. Там же будут лежать и вспомогательные файлы типа bootstrap.php, фикстуры и прочее. В этой папке выделим подпапки Unit, Integration, Functional для самих тестов.При необходимости здесь же будут созданы дополнительные папки. Это позволит разделить файлы тестов и вспомогательные файлы. 

Сразу настроим автозагрузку вспомогательных классов. Для этого в composer.json пропишем секцию.

"autoload-dev": {
   "psr-4": {
       "App\\Test\\": "tests/"
   }
},

Префикс нэймспейса App\Tests\ подходит для большинства случаев. При этом, вы конечно же можете/должны поменять его на свой согласно неймспейса, используемого в вашем проекте.

Установка PHPUnit

Теперь, добавим в проект PHPUnit версии 9.5+ как dev-зависимость. Здесь указана конкретная версия PHPUnit поскольку дальше будут приводиться настройки согласно этой версии.

composer require --dev phpunit/phpunit:^9.5

Сразу оговорюсь, чтобы снять лишние вопросы. PHPUnit можно установить и с помощью symfony/phpunit-bridge в процессе запуска тестов. Однако, я предпочитаю устанавливать PHPUnit в явном виде в dev-зависимости. При этом ускоряется выполнение тестов на CI благодаря многослойной сборке docker контейнера. Но это тема отдельной статьи.

Пакет symfony/phpunit-bridge мы тоже установим. Но для других целей. Не для запуска тестов и установки PHPUnit в процессе исполнения, а для отображения списка сработавших депрекейшенов в конце выполнения тестов.

После установки PHPUnit у нас в корне проекта должен появиться файл phpunit.xml.dist. Здесь нас сейчас интересует:

1. указание пути к bootstrap файлу. Атрибут bootstrap тега phpunit.

2. указание пути к тестам. Сейчас у нас будет единственный testsuite (набор тестов).

   
       
       
       
   

   
       
           tests
       
   

Загрузка переменных окружения

В Symfony проектах принято описывать большинство переменных окружения в .env файлах. В том числе для тестов. Для этого нам пригодится tests/bootstrap.php файл. Выкидываем оттуда стандартную обработку PHP файла с переменными окружения, которого у нас нет, но добавим обработку иерархии .env файлов, чтобы в локальных файлах и файлах для специфического окружения переопределять только часть переменных, а все остальные будут в основном файле. В этом примере сделана возможность работать не только в тестовом окружении. Это может быть полезно при разработке бандлов в отдельных пакетах.

declare(strict_types=1);

use Symfony\Component\Dotenv\Dotenv;

require dirname(__DIR__).'/vendor/autoload.php';

$env = $_SERVER['APP_ENV'] ?? $_ENV['APP_ENV'] ?? 'test';
$paths = [sprintf('.env.%s.local', $env), sprintf('.env.%s', $env), '.env'];
$paths = array_map(static fn (string $x): string => dirname(__DIR__).\DIRECTORY_SEPARATOR.$x, $paths);
$paths = array_filter($paths, static fn (string $x): bool => is_readable($x) && is_file($x));
$dotenv = new Dotenv('APP_ENV', 'APP_DEBUG');
array_walk($paths, static fn (string $x) => $dotenv->bootEnv($x, $env));

Решение проблемы создания моков final классов

Тут есть два подхода.

Интерфейсы. Много интерфейсов на всё.

Первый вариант решения проблемы моков final классов — это создание интерфейсов. Затем final класс реализует интерфейс и везде в системе в зависимостях указывается интерфейс вместо самого класса. Далее в тестах создаются моки интерфейсов, а не конкретных классов. У этого подхода есть ряд недостатков.

Во-первых, на каждый класс нужно создавать интерфейс, даже если не предполагается альтернативной реализации этого интерфейса. Это приводит к появлению множества мусорных интерфейсов засоряющих систему.

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

Втретьих, как быть с существующим кодом? Как быть с легаси? Это что теперь нужно переписать всю систему, чтобы начать тестировать? Это уже точно ни в какие ворота не лезет.

Обёртка протокола чтения файлов

Второй подход — установка расширения, позволяющего убирать ключевое слово final «на лету» во время чтения файлов ядром PHP за счёт установки обёртки над потоком чтения.

composer require --dev dg/bypass-finals

И включим его в bootstrap файле. Как можно раньше. Сразу после подключения автозагрузчика классов.

use DG\BypassFinals; // [ 1 ]
use Symfony\Component\Dotenv\Dotenv;

require dirname(__DIR__).'/vendor/autoload.php';

BypassFinals::enable(); // [ 2 ]

//...

Метод не без минусов.

Во-первых, все final классы перестают быть таковыми и теоретически можно реализовать наследование от final класса. И такой код выполнится в тестах, но упадёт на проде. Чтобы исключить такое, можно и нужно воспользоваться статическим анализ кода. Например, PHPStan.

Во-вторых, это дополнительная нагрузка за счёт анализа всех зачитываемых файлов на лету и их изменения.

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

Code coverage

Один из важных показателей в тестах — code coverage — показатель покрытия кода тестами. Показатель мягко говоря не однозначный (об этом чуть позже). Чтобы его получить, у нас должен быть установлен xDebug. И в настройках включен нужный режим: xdebug.mode=coverage (см. документацию). Далее в файле phpunit.xml.dist мы указываем какие отчёты хотим получить.

   
       src
   

   
       
       
       
   

И добавляем папку, используемую для отчётов build в .gitignore.

Один из интересных форматов отчётов — это HTML. Вы получаете web страницу с процентами покрытия разных частей приложения, активными ссылками для перехода по папкам и файлам, подсветкой какие строки покрыты тестами, а какие нет.

Отчёт по директории «src»Отчёт по отдельному файлу

Типы тестов

Unit тесты

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

Тут всегда возникает вопрос на сколько элементарными должны/могут быть юнит тесты? Писать ли тесты на геттеры/сеттеры у Entity, DTO и пр.? Не пустая ли это трата времени? Конечно, какой смысл проверять, что метод возвращает массив, когда у этого метода стоит тайпхинт массив? Некоторые умудряются писать такие тесты. При этом даже будет, показано, что увеличилось покрытие кода тестами, поскольку вызвана соответствующая строчка кода. Однако, это мусорный или фейковый тест, который только делает вид, что что-то проверяет. В реальности он не имеет смысла. Да, сейчас геттеры/сеттеры чаще генерируются автоматически с помощью IDE или консольных команд. Тем не менее этот код поддерживается и порой всё же пишется разработчиким вручную. И есть ненулевая вероятность спутать поля и вывести в геттере данные не от того поля. Или вызов одного сеттера может обновить данные в нескольких полях. Или может может быть реализовано преобразование данных в сеттере или геттере. В результате геттер будет отдавать не то, что вы ожидаете. Или может быть путаница с тайпхинтами в геттере/сеттере/проперти и если этот код не будет запущен в тестах, то вы не узнаете о существовании проблемы. В итоге, мой совет — пишите тесты и на геттеры с сеттерами.

В какой-то степени может показаться, что Unit-тесты — это тестирование особенностей реализации. Тем не менее, всегда нужно держать фокус на результате работы скрипта. Например, мы пишем юнит-тест на какой-то сервис, который:

1. Принимает DTO

2. Получает Entity из репозитория

3. Обновляет данные в Entity

4. Сохраняет Entity.

Для его тестирования мы создадим новый инстанс сервиса, установим в него мок репозитория (сейчас не важно через конструктор или публичный сеттер). И подадим в него DTO или её мок. Тут можно замокать все методы у DTO и прописать сколько раз должен быть вызван каждый из методов. Например так:

$dtoMock
->expects($this->once())
->method(‘setSomething’)
//->...

Но что будет для нас самым главным здесь? Число вызовов каждого метода (особенность реализации) или то, что в Entity будут переданы нужные нам данные (бизнес цель)? Скорее всего второй вариант. Конечно есть кейсы, когда обязательно нужно проверить число вызовов того или иного метода. Но нужно каждый раз взвешивать что является целью.

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

Базовый класс, от которого будут наследоваться все Unit тесты: PHPUnit\Framework\TestCase

Интеграционные тесты

Их основная задача — тестирование отдельных блоков кода в приложении. Правильнее сказать, будем проверять работу разных сервисов во взаимодействии с другими сервисами, их интеграцию. Здесь мы уже будет получать готовые сервисы из контейнера Symfony и использовать минимум моков. Например, так:

$someService = static::getContainer()->get('app.some_service');
$someService->call();

Я их называю для себя младшими братьями функциональных тестов. Они могут затрагивать достаточно большие части системы. Тем не менее, мы ещё внутри системы и работаем непосредственно с классами системы.

Базовый класс для интеграционных тестов: Symfony\Bundle\FrameworkBundle\Test\KernelTestCase.

И скорее всего вам понадобится реализовать свой абстрактный класс, расширяющий базовый класс, чтобы поместить туда наиболее часто используемые штуки. Например, получение EntityManager.

Здесь есть нюансы при разработке отдельного бандла. Например для установки его через Composer зависимости в разные проекты. В этом случае у нас нет класса Kernel, нет контейнера и значит не работает dependency injection. Значит нам нужно его создать. Лучше сделать это в папке tests/Stub. Пример для Symfony 5+:

  $client = static::createClient();
$client->request($method, $url, $parameters, $files, $headers);
self::assertSame(200, $client->getResponse()->getStatusCode());

$form = $client->getCrawler()->filter('form[name="custom_form"]')->form();
$values = $form->getPhpValues();

$formData = [ /** some new data */ ];
$values['custom_form'] = array_merge($values['custom_form'], $formData);

$client->request(
   $form->getMethod(),
   $form->getUri(),
   $values,
   $form->getPhpFiles()
);