Я всегда тестировал промежуточное ПО одним из двух способов: модульным тестом с фиксацией и подтверждением обратного вызова в методе handle или интеграционными тестами на маршрутах приложений.
Модульное тестирование
Проблема с модульным тестированием заключается в том, что вам не видно, действительно ли промежуточное ПО активно, и вы также не знаете, как оно будет работать, когда запрос проходит через другое активное промежуточное ПО.
Интеграционное тестирование
Использование интеграционных тестов на маршрутах приложений решает некоторые проблемы с промежуточным программным обеспечением для модульного тестирования, но немного усложняет утверждение о том, как на самом деле работает промежуточное программное обеспечение. Я также обнаружил, что хочу постоянно проверять, что промежуточное ПО активно и работает на каждом из моих маршрутов приложения.
Тестирование промежуточного программного обеспечения
Я хотел найти простой подход, который подтвердил бы следующее:
- ПО промежуточного слоя активно и правильно настроено (глобальное, групповое, одноразовое)
- ПО промежуточного слоя работает правильно
Давайте посмотрим на несколько примеров
Итак, что я здесь сделал, так это определил настраиваемые маршруты тестирования и применил промежуточное ПО так, как я бы использовал его в маршрутах приложений, в данном случае глобальное промежуточное ПО и как промежуточное ПО для группы api. Это позволяет мне утверждать, что промежуточное ПО настроено и работает правильно.
Единственный потенциальный недостаток этого подхода заключается в том, что он по-прежнему полагается на разработчика, чтобы гарантировать правильное назначение промежуточного программного обеспечения маршрутам приложения. Это все еще можно уменьшить, проверив, какое промежуточное программное обеспечение активно на каждом маршруте. Но это не то, о чем я обычно беспокоюсь.
