MVC - модульное тестирование неправильных вещей?

Question

Практикуя некоторые TDD на работе над проектом ASP.Net MVC, я столкнулся с рядом сценариев, в которых я писал тесты, чтобы убедиться, что определенные действия возвращают правильные представления или имеют определенные атрибуты ([ChildActionOnly] и т. Д.),(на самом деле, я нашел здесь несколько интересных постов ТАК о полезных методах расширения, которые помогут достичь этого).

Когда я впервые познакомился с концепциями модульного тестирования и TDD, когда был на курсе несколько лет назадакцент был сделан на том, что тесты должны быть сосредоточены на логике тестирования за желаемыми для пользователя функциями и возможностями - «требованиями» основного проекта, если хотите.

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

Answer 1

Если метод-обработчик может вернуть одно из двух (или более) представлений в зависимости от некоторой логики, тогда будет полезен модульный тест, который подтвердил правильное представление. То же самое касается метода-обработчика, который вставляет определенные атрибуты в зависимости от логики.

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

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

Answer 2

Если ваше действие возвращает разные представления (или результаты действия) в зависимости от некоторой логики. Написать тест.

Если вы всегда возвращаете View (), тогда не делайте.

Если вы возвращаете представление с именем, отличным от имени вашего действия, - тогда вы можете поспорить, что было бы неплохо написать тест.

Answer 3

Действительно, ваши тесты должны проверять вашу логику.Это не должно уйти.Однако в идеале вы должны написать тесты для всего, что может пойти не так.Например, гарантируя, что все методы, которые должны быть защищены, имеют надлежащий атрибут Authorize.Это тест безопасности.

Ultimate, вы сами решаете, что для вас полезно протестировать.

Answer 4

Это зависит.Чтобы использовать один из ваших примеров: Проверка, имеет ли действие определенный атрибут, это нормально, но лучше написать тест, который проверяет, что поведение функционирует должным образом, что потерпит неудачу, если атрибут отсутствует.

Тем не менее, в конечном итоге ваши тесты являются защитной сеткой.Если у него есть разумный шанс предотвратить появление ошибки в какой-то момент в будущем, он выполняет свою работу.

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