Написание и тестирование контроллеров

Написание контроллеров регистрации и их функциональное тестирование. Добавление локальных фикстур для тестовых сценариев. Проверка отправки электронных писем.

Скрытый контент
Комментарии (8)
Bondarenko Alexandr
2020-03-24 09:22

Спасибо за урок, Дмитрий!

У меня есть вопросы:

1) Не удобнее было бы в тестах использовать отдельную базу данных для тестового окружения? Тогда после тестов не пришлось бы опять накатывать фикстуры.

2) При использовании контроллера вне изолированных контекстов бывают сценарии, когда есть необходимость вызвать несколько интеракторов из разных контекстов (по событию или же через "оркестратор"). Есть ли один из них при этом успешно модифицировал данные, а следующий выбросил исключение, следует откатить действие первого. Планируется ли рассмотреть подобный сценарий?

3) Планируется ли рассмотреть Graphql для озвученной в видео возможности чтения запрашиваемых клиентом дополнительных данных у эндпойнта?

Ответить
Deworker Pro
2020-03-24 20:43

Не удобнее было бы в тестах использовать отдельную базу данных для тестового окружения? Тогда после тестов не пришлось бы опять накатывать фикстуры.

Да, есть альтернативы работы с той же БД:

1) Вызывать $em->getConnection()->beginTransaction() в методе setUp() и вызывать rollback() в tearDown(). Тогда тест будет выполняться в транзакции и после теста все данные будут восстанавливаться назад.

2) Подключить ещё один сервис api-postgres-test и указать его в тестовом окружении. И дополнительно накатывать миграции ещё и на неё.

Эти способы сработают только для кода внутри нашего внутреннего теста.

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

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

Так что как удобнее совместить разработку и тестирование - вопрос весьма сложный.

Ответить
Deworker Pro
2020-03-24 20:47

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

Да, это паттерн "Сага". Его рассмотрим.

Ответить
Deworker Pro
2020-03-24 21:38

Планируется ли рассмотреть GraphQL для озвученной в видео возможности чтения запрашиваемых клиентом дополнительных данных у эндпойнта?

Расскажем, что универсальные решения удобны для CRUD-подхода, когда API является отражением один-в-один таблиц в БД. Но если делаем что-то кастомное, то проявляются неудобства.

Так что вдальнейшем сравним подходы к написанию API и выберем оптимальный вариант.

Ответить
Bondarenko Alexandr
2020-03-25 05:52

Спасибо за ответы!

Ответить
Arunas
2020-03-25 07:02

пересмотрел -> большое спасибо.

Ответить
Denis
2020-03-26 09:03

Попробую сформулировать свой вопрос.

Допустим, что у нас появилась необходимость из модуля блог дернуть авторизацию. То как то правильно сделать, чтобы не напрямую дергать код из авторизации? Чтобы модули не были напрямую зависимы друг от друга.

Надо как то дергать контроллер? Надо вводить какую - то абстракцию для этого?

Когда ту же авторизацию вынесут на отдельный сервер из -за нагрузки, допустим, то код просто исчезнет из нашей кодовой базы и надо будет как - то переключить вызовы на другую апи. Как это все реализовать правильно, чтобы не было потом больно? Как абстрагировать свои внутренние вызовы, чтобы потом можно было просто все поправить в одном месте?

Ответить
Deworker Pro
2020-03-28 07:26

Обычно авторизация производится на уровне контроллеров. При нашем подходе с отдельными контроллерами проблем с не будет. А роль пользователя для привязки прав будем передавать напрямую в токене аутентификации.

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий