У нас есть приложение ASP.NET Web Api 2, которое мы находимся в процессе перехода на ASP.NET core MVC.На данный момент приложение функционирует, но нам еще предстоит перенести все наши тесты.Наши текущие тесты работают следующим образом, все эти шаги выполняются для каждого теста:
Настройка (общая для всех тестов)
- Инициализация локальной инфраструктуры (базы данных в памяти и т. д.).
- Настройка DI-контейнера с производственными зависимостями, за исключением компонентов, взаимодействующих с внешним миром, но позволяющих каждому тестовому классу внедрять свои собственные двойники теста путем переопределения простого метода.
- Настройте тестируемый объект (который всегда является контроллером), разрешив его из контейнера DI.
Тест
- Упорядочить: Вставить тестовые данные в локальную БД, подготовить параметры действия контроллера, настроить данные с заглушками ....
- Act: Вызвать действие контроллера.
- Утвердить: Проверить состояние
HttpResponseMessage (код состояния ...) и возвращенный объект (десериализованный с помощью пользовательского помощника), проверка ожиданий ложных / шпионов и / или состояния локальной базы данных.
Разрыв (общий для всех тестов)
- Очистка локальной инфраструктуры.
Как видите, наши тесты ближе к интеграционным тестам , чем модульным тестам , потому что мы всегда используемпочти полный граф зависимостей.Но нам не нужно использовать тестовый сервер, и мы можем напрямую воздействовать на состояние контроллера перед выполнением (установка текущего пользователя и т. Д.).
Это приводит к очень быстрому времени выполнения по сравнению с интеграционными тестами.(сотни тестов выполняются менее чем за минуту) и отличная устойчивость к рефакторингу подуровней (нам не нужно переписывать десятки тестов, когда служба получает новую зависимость или разбивается на 2 компонента).Единственным недостатком является короткое замыкание фильтров и промежуточного программного обеспечения, которое мы должны тестировать отдельно.
ASP.NET Core MVC, по-видимому, не делает такой подход возможным или легким (или даже предлагаемым).
- Должны ли мы преобразовывать наши тесты в интеграционные тесты и использовать встроенный тестовый сервер?Как это повлияет на производительность (разработчики часто запускают весь набор тестов)?
- Должны ли мы переписать 95% наших тестов и придерживаться подхода модульного тестирования Microsoft (одиночный открытый метод тестирования с минимальной глубиной)сохранить только несколько интеграционных тестов в отдельном проекте?
- Есть ли альтернатива, более близкая к нашему первоначальному подходу, позволяющая нам разрешать контроллер из контейнера DI и настраивать его HTTP-контекст перед каждым тестом?Может быть, мы могли бы использовать этот подход хотя бы временно, если это вообще возможно.