[Перевод] 10 советов по тестированию в Symfony30.06.2020 21:02

Я обнаружил, что прекрасный способ очистки БД — загрузить пустые фикстуры в особый метод setUp в PHPUnit. Вы можете сделать это, если у вас установлен LiipFunctionalTestBundle.

loadFixtures([]);
    }
}

Создание данных

Если начинать каждый тест с пустой БД, то нужно иметь несколько утилит для создания тестовых данных. Это могут быть модели создания БД или объекты сущностей. 

В Laravel есть очень простой метод с фабриками моделей. Я стараюсь следовать такому же подходу и делаю интерфейсы, создающие объекты, которые я часто использую в тестах. Вот пример простого интерфейса, который создаёт сущности User:

setEmail($this->faker->email);
        $user->setFirstName($this->faker->firstName);
        $user->setLastName($this->faker->lastName);
        $user->setRoles([User::ROLE_USER]);
        $user->setBio($this->faker->paragraph);

        return $user;
    }

Я могу добавлять такие интерфейсы в желаемый тестовый набор:

createUser();
        
        // Login as user. Do some tests.
    }
}

Замена местами сервисов в контейнере

В Laravel-приложении очень легко поменять в контейнере сервисы местами, а в Symfony-проектах это сложнее. В версиях Symfony 3.4 — 4.1 сервисы в контейнере помечаются как приватные. Это означает, что при написании тестов вы просто не можете обращаться к сервису в контейнере и не можете задать другой сервис (заглушку).

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

К счастью, в Symfony 4.1 можно обращаться к контейнеру и менять сервисы по своему желанию. Например:

createMock(PaymentProcessorClient::class);
        $paymentProcessorClient->expects($this->once())
            ->method('purchase')
            ->willReturn($successResponse);

        // this is a hack to make the container use the mocked instance after the redirects
        $client->disableReboot();
        $client->getContainer()->set(PaymentProcessorClient::class, $paymentProcessorClient)
    }
}

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

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

Исполнение SQLite в памяти

SQLite очень часто используют в качестве уровня хранения данных при тестировании, потому что он очень компактен и очень легко настраивается. Эти качества также делают его очень удобным для использования в CI/CD-окружении.

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

При конфигурировании БД в Symfony-приложении не надо указывать файл database.sqlite, достаточно передать его с ключевым словом :memory:.

Исполнение SQLite в памяти с tmpfs

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

На Linux-системах можно выделить часть оперативной памяти, которая будет вести себя как обычное хранилище. Это называется tmpfs. По сути, вы создаёте tmpfs-папку, кладёте в неё файл SQLite и используете для прогона тестов.

Можете использовать тот же подход и с MySQL, однако настройка будет посложнее.

Тестирование уровня Elasticsearch

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

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

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

Использование фильтров Xdebug для ускорения отчёта о покрытии

Покрытие — важный аспект тестирования. Не нужно относиться к нему как к простому числу, это помогает найти не протестированные ветки и потоки в коде.

Обычно оценкой покрытия занимается Xdebug.

Вы увидите, что запуск анализа покрытия ухудшает скорость тестов. Это может стать проблемой в CI/CD-окружении, где каждая минута стоит денег.

К счастью, можно сделать некоторые оптимизации. Когда Xdebug генерирует отчёт о покрытии исполняющихся тестов, он делает это для каждого PHP-файла в тесте. Сюда входят и файлы, находящиеся в вендорской папке — код, который нам не принадлежит.

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

Как создать фильтры? Это может сделать PHPUnit. Нужна только лишь одна команда для создания файла конфигурации фильтра:

phpunit --dump-xdebug-filter build/xdebug-filter.php

А затем передаём этот конфиг при прогоне тестов:

phpunit --prepend build/xdebug-filter.php --coverage-html build/coverage-report

Инструменты распараллеливания

Прогон функциональных тестов может занимать немало времени. Например, полный прогон набора из 77 тестов и 524 предположений может занять 3–4 минут. Это нормально, учитывая, что каждый тест делает кучу запросов к базе данных, генерирует грозди шаблонов, запускает по этим шаблонам краулеры и делает определённые предположения.

Если вы откроете монитор активности, то увидите, что тесты задействуют только одно ядро вашего компьютера. Задействовать другие ядра можно с помощью инструментов распараллеливания вроде paratest и fastest. Их легко настроить для прогона модульных тестов, а если нужны подключения к базе данных, то может потребоваться повозиться.

Я смог использовать 6 ядер и 12 потоков на своём компьютере, и вместо 4 минут прогонял тесты за 25–30 секунд.

Дополнение: Некоторые полезные комментарии к этой статье можно почитать на r/php. А здесь вы найдёте другие советы и информацию об инструментах.

© Habrahabr.ru