Почему тестирование MVC Views осуждается?

В настоящее время я устанавливаю основу для приложения ASP.Net MVC и изучаю, какие именно юнит-тесты я должен быть готов написать. Я видел во многих местах людей, которые по сути говорили: «Не беспокойтесь о проверке ваших представлений, здесь нет логики, и она тривиальна и будет охвачена интеграционным тестом».

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

Пример сценария. Допустим, мы имеем дело со стандартным приложением CRUD с сущностью Customer. У клиента есть имя и адрес. На каждом уровне тестирования я хочу убедиться, что логика поиска клиента правильно получает и имя, и адрес.

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

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

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

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

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

У меня такое ощущение, что я просто не понимаю какую-то ключевую концепцию. Может кто-нибудь объяснить, почему нежелательно получать немедленные отзывы о достоверности представления MVC? (или если не плохо, то не ожидаемый способ получения упомянутой обратной связи)

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

Для правильного тестирования веб-интерфейса требуется такой инструмент, как Selenium, который будет использовать браузеры на вашем компьютере и обеспечивать правильную работу JavaScript и HTML во всех браузерах. Selenium имеет модель клиент / сервер, поэтому вы можете иметь набор виртуальных машин с клиентами Unix, Mac и Windows, а также набор браузеров, общих для этих сред.

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

Тем не менее, MVC имеет некоторые хорошие возможности для проверки DOM, возвращенного запросом. Это немного уменьшает боль при тестировании слоя вида.

Я бы не сказал, что это осуждается. Скорее, это чувство является результатом того факта, что модульное тестирование представлений MVC (по крайней мере, разновидности aspx) довольно сложно, потому что представления aspx слишком сильно зависят от WebForms, которые сами по себе довольно непроверяемы. Таким образом, аргумент гласит, что это не стоит усилий, потому что взгляды, как правило, не такие сложные.

Конечно, взгляды могут быть довольно сложными, так что это ваш выбор.

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

Он также написал лучшую книгу ASP.MVC (IMO). Он не только преподает MVC, но и делает все возможное, чтобы преподавать лучшие практики, в том числе методы тестирования.

Я думаю, мне нужно немного уточнить представления о модульном тестировании - вы можете создавать модульные тесты на основе результата, возвращаемого контроллером (ActionResult и т. Д.). Вам по-прежнему нужно будет провести другое тестирование для реального интерфейса и взаимодействия с ним.

Вы можете узнать, как проверить представление, возвращаемое действием контроллера, как проверить данные просмотра, возвращенные действием контроллера, и как проверить, перенаправляет ли одно действие контроллера второе действие контроллера, проверив следующий URL-адрес: опишите в этой краткой статье о тестировании View Data в MVC .