Преимущества MVC контроллеров модульного тестирования

Question

В моем приложении уже есть модульное тестирование для уровня домена. Я хотел бы знать, каковы плюсы / минусы контроллера модульного тестирования

и какие тестовые примеры следует писать при тестировании контроллеров.

Спасибо

Answer 1

Зависит.

В контроллерах могут происходить проверки, перенаправление, временные сообщения и т. Д.Вы можете утверждать, что эти операции должны быть проверены так же, как и ваши модели.

С другой стороны, вы должны стремиться к мышлению ' Fat Model, Skinny Controller '.Я стараюсь, чтобы мои контролеры были настолько тупыми, насколько это возможно.Проведите несколько сквозных тестов вокруг функций, которые вас интересуют (Selenium, Cucumber и т. Д.), И они обеспечат правильность ваших контроллеров.Скажем, мы разрабатываем функцию для перечисления некоторых элементов.Если сквозной тест этой функции в порядке, контроллер в порядке.Если это сломается, вы будете знать, что вы ввели регрессию.В сочетании с этим у меня есть только тесты, которые проверяют правильность представлений и корректный ответ - перенаправление, json и т. Д. Любое больше тестов на вашем контроллере , и у вас логика не в том месте.

В ASP.NET MVC2 Стивом Сандерсоном он делает несколько замечательных замечаний по поводу приведенных выше рассуждений.Я полностью рекомендую это.Недостаток этих простых тестовых контроллеров состоит в том, что я могу легко открыть вашу кодовую базу, внести изменения и сломать ваше приложение.До тех пор, пока происходят правильные представления / ответы, приложение будет по-прежнему функционально исправным.

Я должен добавить, что тестирование службы вызывается в контроллере с правильными параметрами, что является тривиальным и быстрым, поскольку вы можетехорошо сделайте это независимо от того, тестируете ли вы свои контроллеры косвенно.Я склоняюсь к этому подходу в целом.Итак, полный ответ на ваш вопрос - да, проверь свои контроллеры;)

Answer 2

Некоторые вещи, которые стоит проверить в действиях контроллера:

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

Answer 3

Одна из проблем, с которыми я столкнулся при тестировании контроллеров, заключается в том, что в некоторых случаях вам нужно эмулировать цепочку выполнения, которой придерживается ASP.NET MVC, чтобы по-настоящему протестировать ваш контроллер.код в вашем методе OnExecuting, вам нужно найти способ запустить этот метод, когда вы выполняете фактический метод действия в вашем контроллере во время модульного теста.

Answer 4

Несмотря на то, что вы всегда должны стараться не допускать бизнес-логики в свои контроллеры, часто бывают случаи, когда построение модели представления может быть настолько сложным, что его легко протестировать.

Например, при отображении представления с несколькими меню выбора, которые заполняются сложными запросами linq к вашей базе данных через пользовательские модели представлений.Такая логика не является бизнес-логикой, поэтому не представляется правильным поместить ее на бизнес-уровень.С другой стороны, его нужно протестировать.

Редактировать: Чтобы пояснить, я не имею в виду ставить запросы на выбор в вашем представлении.Это подтвердило бы паттерн MVC.Я имею в виду контроллер, который выполняет такие запросы и создает сложные пользовательские модели представлений с результатами для отображения представлений.

Answer 5

A 'Pro' думал:

В случаях, когда вы передаете количественные данные или параметры из контроллера в представление.

В некоторых случаях, хотя я считаю ограниченным или редким, нужно проверить внутреннюю логику в контроллере, которая не охватывается вашими тестами вспомогательного кода.Хотя можно утверждать, что эти части кода следует переместить.

A 'Con' Thought:

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