asp поблочного тестирования mvc представление
Как может я модульный тест представление приложения MVC ASP?
Я попробовал mvc contrib, тестируют помощника...
_controller.Index().AssertViewRendered();
но это на самом деле не тестирует представление.
например, я могу счастливо ввести некоторый поддельный код в представлении и получить страшный желтый экран смерти без моего модульного теста, когда-либо зная об этом.
Есть ли какой-либо estabilished метод выполнения этого? Мне нужна насмешка механизм представления? mvccontrib угождает этому?
Я думал бы, что это будет очень общим требованием, но я не могу найти много об этом!
Спасибо
ОТРЕДАКТИРУЙТЕ то, Что я действительно, после время компиляции, проверяя, чтобы гарантировать, чтобы образцовые изменения не влияли на представление.
этот вопрос содержал инструкции включить компиляцию представления времени изготовления, которая достаточна для меня на данный момент. Скомпилируйте Представления в ASP.NET MVC
4 ответа
Есть 3 варианта:
- Вы хотите выполнить модульное тестирование кода в представлении. В этом случае вы должны переместить код в контроллер, потому что представление не несет ответственности за этот код.
- Вы хотите, чтобы представление действительно отображалось в браузере. Используйте инструмент тестирования пользовательского интерфейса браузера, например waitin или selenium. Это создает не изолированную проверку представления, а большую часть вашего приложения. Звучит как преимущество, но есть ли какая-то ценность в изолированном тесте представления?
- Вы хотите проверить, что код в вашем представлении является компилируемым кодом. Затем скомпилируйте код. Это можно сделать в модульном тесте, вручную вызвав view.compile или включив компилятор представления в процессе сборки.
Юнит-тесты обычно никогда не тестируют UI, потому что он просто слишком хрупкий для этого.
Хотя вы можете утверждать, что минимальный тест должен заключаться в том, что представление не падает с исключением, когда мы пытаемся его отобразить, это также будет единственным модульным тестом, который мы можем написать для представления (ASP.NET MVC, WPF, Windows Forms и т.д. - это не имеет значения).
Следующее, что вы (или ваш клиент) захотите проверить, - это правильность отображения представления, и вы не сможете надежно сделать это с помощью автоматизированного теста. Все сводится к тому, что представления лучше тестировать с помощью визуальной инспекции, потому что возврат инвестиций на это просто лучше, чем пытаться разрабатывать и поддерживать автоматизированные тесты пользовательского интерфейса.
Вам следует изучить инструменты веб-тестирования в наборе MS Test или один из ряда других инструментов веб-тестирования, например Selenium , чтобы проверить представления, если вам нужны автоматизированные тесты для них. Я думаю, вам будет проще, чем адаптировать фреймворк для модульного тестирования.
Полное раскрытие: я все еще тестирую свой пользовательский интерфейс вручную. Я не нашел достаточно преимуществ, чтобы перевесить затраты на обучение, настройку и поддержку веб-тестов.
Мой совет - не утруждать себя тщательной проверкой своих взглядов. Это сложно, и если вы все делаете правильно, в этом все равно не будет много логики.
Тем не менее, WatiN - хороший инструмент для автоматического тестирования браузеров - не совсем то, что вы хотели, но он работает хорошо.