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

23

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

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

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

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

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

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

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

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

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

Питер Бернье
источник
1
"To unit-test the repository, I write an integration test"Чего ждать? Это не модульный тест хранилища. Вы автоматизируете тест для него, но тестируемый код все еще включает DAL и базу данных. Для модульного тестирования репозитория вы должны изолировать его, как и для своих бизнес-правил.
StuperUser
Модульное тестирование представления, отображаемого, как и ожидалось, является всего лишь модульным тестированием работы вашего движка шаблонов Это похоже на модульное тестирование вашего скомпилированного C, содержащего определенные фрагменты машинного кода, ваше модульное тестирование компилятора, а не вашего кода.
Raynos
2
@Raynos С уважением, я собираюсь не согласиться. Если я (или другой разработчик) ошибочно подключаю пользовательский интерфейс для отображения одного атрибута данных в поле пользовательского интерфейса для другого (например, «Имя» в «Поле фамилии», это не имеет ничего общего с механизмом шаблонов, ни это проблема DAL или BR .. это, очевидно, проблема, которая будет видна только на виде
Питер Бернье
1
@PeterBernier у вас есть хорошая точка зрения, но мне трудно определить грань между «проверкой работоспособности компилятора» и «проверкой работоспособности моего кода». Не говоря уже о том, что тесты для пользовательского интерфейса тесно связаны с пользовательским интерфейсом. Любые изменения в пользовательском интерфейсе приводят к сбою тестов. На самом деле вы не можете выполнить рефакторинг пользовательского интерфейса, не провалив тест.
Райнос

Ответы:

9

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

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

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

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

Берин Лорич
источник
1
«По сути, все, что вам нужно сделать, - это утверждать, что возвращаемый HTML содержит нужные вам элементы». Это именно то, что я пытаюсь сделать, и это оказывается нетривиальным. Можете ли вы указать ссылку, по которой это будет работать с определенным действием контроллера, а не с простым рендерингом элемента управления? (Я работал над несколькими рецензиями, но RenderPartial не выполняет то, что я хочу, без значительных накладных расходов ...)
Питер Бернье
Вы хотите проверить mvccontrib.codeplex.com (MVC Contrib). Это обеспечивает помощь, которая не была встроена в основной язык и была рекомендована в книге «Test-Drive ASP.NET MVC» (прагматичные программисты). Я все еще думаю, что Selenium лучше подходит для тестирования View.
Берин Лорич
TestHelper (MVC Contrib): mvccontrib.codeplex.com/…
Берин Лорич
Selenium (в моем случае Selenium RC) - это то, что я буду использовать для интеграционных тестов. Я хочу, чтобы до этого момента произошел сбой.
Питер Бернье
2
@Peter: Ваш комментарий о том, что ваши усилия были «нетривиальными», как раз и является причиной того, что взгляды модульного тестирования не одобряются. Следовательно, типичная стратегия состоит в том, чтобы сделать представления как можно более тонкими (то есть не содержащими бизнес-логики), чтобы большая часть модульного тестирования могла проходить где-то еще (обычно в ViewModel). Сами представления можно проверить визуальным осмотром или с помощью инструмента тестирования пользовательского интерфейса, такого как Selenium.
Роберт Харви
7

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

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

marcind
источник
3
Насколько мне известно, представления ASP.NET MVC не привязаны к веб-формам. Разве для ASP.NET MVC не одно из главных преимуществ в том, что это не Webforms?
Адам Лир
Моя точка зрения состоит в том, что для написания интеграционных тестов для пользовательского интерфейса требуется больше человеческих усилий, чем для написания реальных «модульных тестов» для представлений. Вот почему я пытаюсь понять некоторую сопротивляемость написанию юнит-тестов для представлений.
Питер Бернье
@ Анна Aspx представления построены на основе веб-форм. Они происходят от System.Web.UI.WebControls.Pageкласса, используют <asp:ContentPlaceholder>элементы управления и т. Д. То, как MVC выполняет их, позволяет избежать большого количества конвейеров выполнения страниц, обычно связанных с WebForms, но при этом все еще использует много материала WebForms под прикрытием.
Марсинд
Если вы используете другой механизм просмотра (например, бритву), вы сможете отодвинуться дальше от механизма Webforms.
Маффин Человек
6

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

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

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

Марк Фридман
источник
«Вам все равно нужно будет провести другое тестирование для реального интерфейса и взаимодействия». В этом и заключается мой вопрос: почему тесты пользовательского интерфейса внезапно становятся частью «другого тестирования» (т. Е. Интеграционного тестирования). Я видел много контента Стива Сандерсона, и именно от этого я начал этот путь, в основном пытаясь повторить то, что он делает со своим проектом «MvcFakes», и столкнулся с проблемами с его кодом, написанным для старых выпусков MVC. .
Питер Бернье
1

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

Jaypee
источник