Тесты на Codeception для PHP-бэкендов

[pavelstashevsky]

Поскольку это высокоуровневые тесты, то мы проверяем логику работы с RabbitMQ/Kafka в рамках конкретных бизнес-процессов.
Как правило, это два сценария — на чтение и запись:

1. Положить валидное сообщение в очередь/топик, прочитать его. Или положить невалидное сообщение (без какого-то обязательного поля, просто мусор и т.д.), проверить как его обработает приложение.
2. Выполнить операцию внутри приложения, которая что-то пишет в очереди/топики, и проверить, что все сгененерировались корректно.

[kavw]

Спасибо за доклад.
Вы упомянули модуль Db, а также то, что используете Doctrine.
Но не упомянули модуль Doctrine2 (https://codeception.com/docs/modules/Doctrine2).
Вы его не используете? Если нет, почему?

[pavelstashevsky]

Мы его не используем, в нем не очень удобно персистить в базу связанные объекты, особенно если их много. И опять же все свойства для объектов нужно передавать через массив.
В случае DoctrineFixturesBundle получается более читабельный код.

[dmitriy2904]

Можете уточнить по поводу раскатки базы данных — она делается один раз перед запуском тестов на bamboo? Данные от предыдущих тестов в одном запуске не мешают?
Как выглядит запуск одного-двух тестов в окружении разработчика, как разворачивается бд в этом случае?

[pavelstashevsky]

Локально и на bamboo у нас одна схема работы с БД:

1. Поднимаем контейнер с БД.
2. Раскатываем структуру и справочники миграциями. База раскатана и больше не перекатывается.
3. Перед каждым тестом чистим таблички и заполняем нужными данными с помощью DoctrineFixturesBundle. Каждый тест получается атомарным, друг на друга никак не влияют.

[djtahoma]

В таком сценарии сильно увеличивается время прогона тестов, верно?

[pbatanov]

Существуют всякие оптимизации, позволяющие срезать углы. Например можно подменить ваш коннект к БД и провести весь тест в транзакции, которую потом просто откатить. Это быстро.

Но как и любое срезание углов должно быть пользовано с умом. Например с такими штуками нельзя запускать процессы, мутирующие БД вне процесса тестирования (например симулировать запуск крон команды в шелле или дернуть реальный контейнер с приложением по API).

А так все по классике пирамиды тестирования. Чем больше тест приближен к реальному использованию — тем он сложней и дороже запускается.