Я использую TDD в течение нескольких месяцев, теперь я хотел бы узнать, как тестировать мои контроллеры (MVC).
Модульные тесты производятся путем тестирования наименьшей единицы каждой функциональности. Иногда контроллеры не маленькие. Они захватывают данные из моделей и передают их в представления.
Как я должен unit test контроллер? Должен ли я высмеивать зависимости контроллера?
Проверяются ли тесты контроллеров интеграционными тестами?
Спасибо.
Я делаю TDD довольно долгое время. Я делаю TDD с ASP.NET MVC более года.
Я начал с канонических правил: "нет строки кода без модульных тестов", поэтому я тестировал все - включая контроллеры. Контроллеры должны быть протестированы, это была одна из целей структуры MVC. Сделайте эти материалы проверенными.
Для небольших приложений, которые подходят, работает очень хорошо. Почти вся логика находится внутри контроллера, все очень хорошо проверено.
Но пока я продолжал работать с MVC, я начал передумать. Я стараюсь держать контроллеры как можно более тонкими. В идеале не более, как делегирование вызова некоторому бизнес-объекту и завершение результатов. Остальное - с помощью фильтров.
Это хорошо сработало для меня! У меня есть бизнес-объект, который реализован/протестирован отдельно, поэтому контроллер - это просто точка интеграции. Нет причин тестировать точку интеграции, поскольку она мала.
Что касается интеграционных тестов: я еще не встречал ситуацию, когда мне это действительно нужно. Не забывайте, что контроллеры всегда зависят от абстракций, которые вы вводите конструктором. Пока у вас есть "хорошие" предположения о том, как работают эти абстракции, вы создаете правильные модульные тесты. По мере неудачи вы просто корректируете модульные тесты.
Интеграционные тесты важны и полезны, но я стараюсь создавать их как можно меньше.
Я использую тот же подход к контроллерам, что и Александр Б. Мои контроллеры тонкие и немые. Однако я все еще пишу тесты для них, чтобы убедиться, что они правильно называют бизнес или объекты обслуживания и передают правильные параметры.
Это, вероятно, лучше всего иллюстрирует фактическая ошибка, которую я, наконец, поймал на прошлой неделе. У меня есть контроллер, который позволяет менеджерам утверждать или отклонять запросы от пользователей, имеет два представления, представление списка невыполненных запросов и подробное представление для каждого запроса. Обе точки зрения могут утверждать или отрицать. Служба, к которой обращается контроллер, имеет кучу других открытых методов, в том числе один для изменения статуса запросов... вы можете видеть, где это происходит. В представлении списка был указан правильный метод для утверждения или отклонения и запуска рабочего процесса, представление сведений только называлось методом изменения статуса и не запускало дальнейший рабочий процесс. Это была моя ошибка в кодировке, но для жизни меня я не мог видеть ее целую вечность - рабочий процесс работает в фоновом потоке, и я потратил неделю на эти темы, считая, что это ошибка в этом разделе.
Итак, для меня
и др.
Тот же вопрос задал вчера:
Имеет ли смысл тестировать контроллеры
И на мой взгляд - ДА, имеет смысл тестировать контроллеры. Вы можете:
Чтобы разработать unit test для вашего контроллера, естественным способом является издевательство над интерфейсами, от которых зависит контроллер ( "вещи", которые он контролирует, позвоните им IControllable s). Затем вы можете проверить, что контроллер управляет контролируемыми объектами ожидаемым способом.
Если взаимодействие между контроллером и контролируемыми объектами затруднено, могут быть сделаны специальные тесты интеграции. Например, может быть серия классов, реализующих IControllable - каждая из этих реализаций будет хорошо работать вместе с контроллером? Возможно, несколько разных IControllables будут взаимодействовать (использовать один и тот же ресурс)? Или у IControllables могут быть сложные способы настройки их влияния на их поведение? Способ проверки этого состоит в том, чтобы написать многоразовый набор тестов, в котором вы накапливаете ряд подозрительных реализаций или комбинаций IControllable.
И последнее, но не менее важное: TDD также относится к приемочным испытаниям. Таким образом, при выполнении TDD у вас также будет сквозной тест высокого уровня для выполнения сценариев, которые распознает конечный пользователь. Скорее всего, они также проведут контроль над контроллером - таким образом, также проверим правильную интеграцию между вашим контроллером и (определенными) классами.