Ответ 1
У меня есть хорошие результаты. Меня не волнует, что кто-то еще здесь говорит о необходимости проверки просмотров, как только вы добавляете свою первую строку кода в представление, даже если код строго связан с представлением, вы вводите потенциал для ошибок, для которых было бы неплохо написать автоматизированные тесты. Мой основной интерес состоит в том, чтобы поймать как можно больше белых и желтых экранов/ошибок. Для этого я использовал фрагмент из вступительного сообщения в блоге Стивена, чтобы убедиться, что страница отображается правильно, не выбрасывая никаких исключений:
Assert.IsTrue(result.ResponseText.Contains("<!DOCTYPE html"));
Маленькие подводные камни, которые я вижу в этой структуре, могут быть:
- Если ваш веб-сайт выполняет довольно сложную привязку к модели между представлениями и методами действий, вы можете обнаружить, что создаете несколько довольно крупных именных объектов, таких как в этом примере (метод действия, который фактически принимает объект модели представления LogonModel), поскольку Я не вижу способа передать какие-либо сложные типы объектов модели представления в ваши методы действий с помощью этой структуры:
var result = browsingSession.ProcessRequest("/account/logon", HttpVerbs.Post, new NameValueCollection
{
{"UserName","myName"},
{"Password", "myPassword"},
{"returnUrl", "/home/myActionMethod"}
});
- Выполнение browsingSession.ProcessRequest( "url" ) создает хост/контекст приложения, который фактически выполняет тестируемый веб-код с использованием конфигурации в тестируемом проекте. Это означает, что тесты выполняются немного медленно и могут модифицировать реальные данные, так как я не вижу быстрого и простого способа обмена хранилищами доступа к данным в тестируемом веб-проекте поддельными версиями с использованием любого объекта, встроенного в этот тест-рамки. Другими словами, вам, вероятно, придется катиться самостоятельно, используя некоторые средства на основе web.config.