Как стать автором
Обновить

Комментарии 8

НЛО прилетело и опубликовало эту надпись здесь
Поскольку это высокоуровневые тесты, то мы проверяем логику работы с RabbitMQ/Kafka в рамках конкретных бизнес-процессов.
Как правило, это два сценария — на чтение и запись:
  1. Положить валидное сообщение в очередь/топик, прочитать его. Или положить невалидное сообщение (без какого-то обязательного поля, просто мусор и т.д.), проверить как его обработает приложение.
  2. Выполнить операцию внутри приложения, которая что-то пишет в очереди/топики, и проверить, что все сгененерировались корректно.
Спасибо за доклад.
Вы упомянули модуль Db, а также то, что используете Doctrine.
Но не упомянули модуль Doctrine2 (https://codeception.com/docs/modules/Doctrine2).
Вы его не используете? Если нет, почему?
Мы его не используем, в нем не очень удобно персистить в базу связанные объекты, особенно если их много. И опять же все свойства для объектов нужно передавать через массив.
В случае DoctrineFixturesBundle получается более читабельный код.
Можете уточнить по поводу раскатки базы данных — она делается один раз перед запуском тестов на bamboo? Данные от предыдущих тестов в одном запуске не мешают?
Как выглядит запуск одного-двух тестов в окружении разработчика, как разворачивается бд в этом случае?
Локально и на bamboo у нас одна схема работы с БД:
  1. Поднимаем контейнер с БД.
  2. Раскатываем структуру и справочники миграциями. База раскатана и больше не перекатывается.
  3. Перед каждым тестом чистим таблички и заполняем нужными данными с помощью DoctrineFixturesBundle. Каждый тест получается атомарным, друг на друга никак не влияют.
В таком сценарии сильно увеличивается время прогона тестов, верно?
Существуют всякие оптимизации, позволяющие срезать углы. Например можно подменить ваш коннект к БД и провести весь тест в транзакции, которую потом просто откатить. Это быстро.

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

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