Текст книги "Asp.net mvc framework"
Автор книги: Гайдар Магдануров
сообщить о нарушении
Текущая страница: 14 (всего у книги 17 страниц)
Здесь мы объявляем глобальный обработчик, который выполнится после загрузки документа $(document).ready (...). В этом обработчике мы задаем поведение для обработки нажатия пользователя на необходимую нам ссылку с идентификатором $(«#checkUsername»).bind(«click», ...). В самом обработчике нажатия производятся следующие действия: получается значение введенного пользователем логина и с помощью функции load производится запрос на сервер для проверки пользовательских данных.
Нетрудно заметить, что в случае с jQuery нам пришлось произвести меньше действий. Во-первых, вместо определения серверного кода с определением Ajax.ActionLink мы сформировали с помощью HTML-разметки обыкновенную ссылку. Во-вторых, для передачи параметра с пользовательскими данными в случае jQuery нам не пришлось работать с внутренними объектами ASP.NET Ajax, вместо этого мы работали со ссылкой напрямую, сформировав ссылку для запроса обыкновенным сложением строк. И в-третьих, само количество кода для jQuery оказалось меньшим, чем потребовалось написать кода для ASP.NET Ajax.
Примечание
Следует заметить, что передача на сервер пользовательского ввода всегда сопряжена с опасностью. Злоумышленник может ввести в виде текста опасный код, например кусок SQL-кода или JavaScript-кода, который затем, в случае когда не проводится проверка пользовательского ввода, будет исполнен вашим сервером или браузером на компьютерах ваших пользователей. Чтобы избежать этого, необходимо всегда обрабатывать пользовательский ввод и учитывать его потенциальную опасность.
***********************************
Пример 2. Логин через Ajax
Второй пример будет представлять собой реализацию авторизации пользователя без перезагрузки страницы, с использованием только Ajax-запросов. Кроме того, сделаем так, чтобы возможность произвести вход в систему была доступна с любой страницы проекта.
Первоначально переопределим действие LogOn в контроллере Account так, чтобы поддержать возможность произведения входа в систему черезе Ajax-запросы (листинг 7.2).
Листинг 7.2. Переопределение действия LogOn
public ActionResult LogOn(string userName,
string password,
bool rememberMe,
string returnUrl)
{
if (Request.IsAjaxRequest())
{
var result = new AjaxResult();
if (!ValidateLogOn(userName, password))
{
result.IsSuccess = false;
result.ErrorString = «введен неверный логин или пароль»;
return Json(result);
}
FormsAuth.SignIn(userName, rememberMe);
result.IsSuccess = true; return Json(result);
}
else
{
if (!ValidateLogOn(userName, password))
{
return View();
}
FormsAuth.SignIn(userName, rememberMe);
if (!String.IsNullOrEmpty(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction("Index", "Home");
}
}
}
Обратите внимание на выделенный в листинге 7.2 фрагмент. В нем используется метод Request.IsAjaxRequest() для определения типа запроса. Если запрос был произведен с помощью Ajax, то выполнятся дальнейшая обработка и возврат результата в виде JSON-данных с булевым значением, описывающим, произведен ли вход в систему, и строкой описания ошибки, если она возникла. Когда запрос не является Ajax-запросом, выполняется предыдущая логика.
Реализация на ASP.NET Ajax
Сделаем так, чтобы вход в систему был возможен на любой странице проекта (рис. 7.10). Для этого добавим разметку, необходимую для отображения элементов управления входа в систему, в элемент управления LogOnUserControl.ascx:
<% if (Request.IsAuthenticated) { %>
Welcome <%= Html.Encode(Page.User.Identity.Name) %>!
[ <%= Html.ActionLink("Log Off", "LogOff", "Account") %> ]
<% } else { %>
<% using(Ajax.BeginForm(«LogOn», «Account»,
(object) null,
new AjaxOptions{OnSuccess = «OnLogon»,
OnFailure = «OnError»})) {%>
Логин: <%= HtmL.TextBoxC'userNams'') %>
Пароль: <%= Html.Password («password») %>
<%= HtmL.CheckBox(«RememberMe») %> запомнить
<% } %>
Welcome !
[ <%= Html.ActionLink("Log Off", "LogOff", "Account") %> ]
<% } %>
Здесь в выделенном фрагменте кода с помощью вспомогательного метода Ajax.BeginForm объявляется форма для ввода данных. Устанавливаются параметры формы: действие, контроллер, которые требуется вызвать. С помощью определения экземпляра AjaxOptions определяются параметры Ajax-запроса: при успешном запросе будет вызвана JavaScript-функция onLogon, при возникновении ошибки будет вызваана другая функция – onError. Определим логику этих JavaScript-функций, которые будут реагировать на результат Ajax-запросов (листинг 7.3).
Листинг 7.3. JavaScript-код для реагирования на события
Здесь определяются две JavaScript-функции: OnLogon и OnError. Первая функция предназначена для обработки результата успешного выполнения авторизации. Функция OnLogon принимает один параметр – result, который содержит результат выполнения запроса и дополнительные данные. Для получения JSON-данных, которые были получены от действия LogOn, в функции OnLogon используются сужебные функции ASP.NET Ajax:
□ get_response – возвращает объект с данными ответа от сервера;
□ get_responseData – позволяет получить строку данных, которые были возвращены действием контроллера;
□ Sys.Serialization.JavaScriptSerializer.deserialize – преобразует строку с JSON-данными в объект с соответствующими полями.
После обработки ответа и извлечения полученных данных, в зависимости от результата, формируется либо разметка, соответствующая приглашению пользователя, либо выводится строка с сообщением об ошибке.
Реализация на jQuery
Для реализации поставленной задачи с помощью jQuery необходимо определить следующую разметку элементов управления:
Здесь определена стандартная форма для отправки данных на сервер. Для обработки работы формы и формирования Ajax-запроса необходимо переопределить поведение формы с помощью JavaScript. Далее представлен фрагмент кода, определяющий логику работы формы:
Здесь определяется обработчик окончания загрузки документа, который после загрузки сайта в браузере у клиента выполнит необходимые привязки к разметке. Так, с помощью $('#loginForm').submit определяется функция, которая будет вызвана в момент, когда данные с формы будут передаваться на сервер. Обратите внимание на параметр event этой функции. После определения своей логики поведения при отправке данных с формы мы вызываем event.preventDefault(), который предотвращает поведение по умолчанию, т. е. позволяет нам отменить отправку данных с формы стандартным путем.
Для отправки данных мы используем функцию $.post, передав в нее предварительно сформированные данные, полученные с элементов управления. При вызове $.post мы определяем функцию OnResult, которая должна быть вызвана после завершения Ajax-запроса. Эта функция определяет обработку результата запроса и выводит либо сообщение об ошибке, либо приглашения для пользователя, в случае когда вход в систему был произведен удачно.
Полезные советы
В этой части главы мы рассмотрим несколько моментов, связанных с использванием технологии Ajax и библиотек jQuery и ASP.NET Ajax на практике.
Вопросы безопасности
Использование Ajax открывает новые возможности для разработчика и предлагает новый опыт для посетителя веб-ресурса. Но вместе с тем использование Ajax открывает новое поле действия для злоумышленников. Рассмотрим основные вопросы безопасности, которые следует иметь в виду при работе с запросами, в том числе и Ajax-запросами.
Обработка пользовательских данных
При работе с данными, полученными от пользователей, всегда необходимо соблюдать правила безопасности. Нужно относиться к любым таким данным как к потенциально опасным для отображения в разметке. Представим себе ситуацию, когда злоумышленник вместо того, чтобы ввести в поле своего логина какой-то текст, вводит туда опасный JavaScript-код. Тогда, если не принять никаких мер предосторожности, каждый из пользователей, который будет открывать страницу с выведенными данными злоумышленника на нашем сайте, потенциально будет уязвим. Предотвращение таких атак достигается путем декодирования опасного содержимого перед отображением на клиенте. В ASP.NET MVC существует метод расширения Html.Encode, который позволяет представить любой набор текстовых данных как безопасную последовательность символов и их HTML-представлений. Рассмотрим пример:
<%= Html.Encode("") %>
Очевидно, что если вывести строку, содержащую тег
Как можно убедиться, метод расширения Html.Encode декодировал опасную строку в такую последовательность, которая выводится браузером как обычная строка текста, безопасная для клиентов.
При работе с Ajax иногда возникает необходимость возвращать данные в виде HTML-разметки, содержащей пользовательские данные. Это может привести к нарушению безопасности и атаке описанной ранее. Для предварительной обработки данных в действиях контроллера можно использовать методы статического класса Httputility. Httputility содержит массу методов для большинства сценариев обработки потенциально опасных данных: HtmlEncode, HtmlAttributeEncode, UrlEncode, UrllPathEncode.
Для более надежной защиты и предоставления дополнительного функционала Microsoft предлагает разработчикам бесплатную библиотеку AntiXSS, которая на момент написания книги имела версию 3.1 (библиотека доступна по адресу http://www.codeplex.com/AntiXSS). Данная библиотека обеспечивает еще более надежное декодирование потенциально опасных данных для обеспечения повышенных требований к безопасности. Кроме того, AntiXSS содержит полезные методы для разнообразных сценариев работы с данными и HTTP-модуль, который позволяет комплексно решать вопросы безопасности для проекта.
Управление данными и cookie
Применение cookie для сохранения информации используется веб-ресурсами очень часто. Практически каждый ресурс реализует с помощью cookie возможность автоматической авторизации пользователя, если он пожелал этого при первой авторизации. Каждый из вас наверняка знает все эти галочки «запомнить меня» на разнообразных ресурсах, которые здорово помогают пользователям, т. к. позволяют не тратить им время и нервы на ввод данных логина, пароля, а порой и замысловатой CAPTCHA-строки.
Однако следует знать, что использование cookie может привести к уязвимости сайта и к раскрытию пользовательских данных. Представим ситуацию: некоторый сайт производит обновление данных на базе строки запроса, полагаясь на произведенную авторизацию пользователя. И разумеется, данный сайт содержит современный механизм авторизации на базе cookie. Может сложиться впечатление, что это абсолютно безопасно, т. к. cookie хранится на компьютере пользователя, а обновление данных невозможно без подтвержденной авторизации. Однако здесь кроется ошибка, которая может привести к серьезному нарушению безопасности. Не будем предполагать, что cookie попросту может быть украден с компьютера пользователя, допустим, что вы предусмотрели такой вариант и кроме cookie проверяете еще и IP-адрес пользователя. Существует более простой вариант атаки и без доступа к cookie. Этот способ предполагает формирование на странице атакуемого сайта изображения с помощью доступного пользователям функционала. Только вместо адреса изображения злоумышленник может подставить строку запроса на модификацию данных. В таком случае все пользователи, зайдя на ресурс, при попытке просмотра картинки выполнят опасную строку запроса от своего имени. И в случае, если через строку запроса можно управлять данными, такой запрос может привести к печальным последствиям.
Мораль такова, что необходимо избегать управления пользовательскими данными через GET-запросы, которые формируются в том числе и строкой запроса. Все запросы, которые так или иначе приводят к модификации, созданию или удалению данных, необходимо оформлять через POST. Однако часто это очень неудобно для разработчика или вовсе невозможно. В таких случаях полезным будет следующее решение:
□ для каждой пользовательской сессии формируется некая строка с уникальным значением;
□ для всех запросов, которые модифицируют данные пользователя, добавляется некий параметр, содержащий сформированное уникальное значение, например, так: http://mysite/LogOut?hash=328947236401603167, где параметр hash содержит секретное значение, полученное на сервере;
□ в функционале, который занимается модификацией данных, производится проверка на переданное значение параметра, в случае если оно отсутствует или не соответствует созданному, предполагается нарушение безопасности;
□ злоумышленник не сможет сформировать строку параметра безопасности, т. к. не знает ее, и описанная ранее атака не сможет быть произведена путем подмены строки запроса.
Однако POST-запросы тоже могут быть подвергнуты атаке. Так, злоумышленнику достаточно сформировать страницу в Интернете, где он создаст форму с автоматической отправкой данных на атакуемый сайт. Ничего не подозревающий пользователь, открыв такую страницу, скрытно для себя авторизуется на своем сайте, предоставляя злоумышленнику выполнять от его имени любые операции. Этот тип атаки получил название Cross-Site Request Forgery (CSRF).
Защита от CSRF может быть осуществлена несколькими путями:
□ проверка поля Referer POST-запроса может показать истинный сайт, с которого производился запрос, на основании этой проверки можно защититься от атаки;
□ для каждой формы можно сформировать скрытое поле со сформированными секретными данными так, как мы делали это для GET-запросов. При отправке данных с формы скрытое поле также будет отправлено. Нам достаточно просто проверить соответствие переданных данных со сформированными на сервере, чтобы убедиться в том, что POST-запрос безопасен.
ASP.NET MVC содержит вспомогательный набор инструментов для реализации второго сценария защиты от CSRF-атак. Инструменты представляют собой метод расширения Html.AntiForgeryToken, который формирует скрытое поле в разметке:
<% using (Html.BeginForm()) { %>
... // здесь набор элементов управления
<%= Html.AntiForgeryTokenO %>
<% } %>
На примере показано использование метода расширения Html.AntiForgeryToken, который в результате сформирует следующую разметку:
value="71QjBJILoVngYTD+UZ3JTn8KMsJ/Yo48Q2sSOLo6cgpYHc2qOG4UudRujINZtg4L" />
Для проверки этого скрытого поля на сервере необходимо добавить к вызываемым действиям атрибут ValidateAntiForgeryToken так, как показано во фрагменте кода:
[ValidateAntiForgeryToken()]
public ActionResult ChangePassword(string currentPassword,
string newPassword, string confirmPassword)
Теперь любой POST-запрос к действию ChangePassword приведет к сопоставлению скрытого параметра формы с внутренним, сформированным на сервере. В случае, если параметры не совпадают, возникнет исключение, которое предотвратит несанкционированный доступ (рис. 7.11). Таким образом, проделав несложные действия, вы надежно защитите себя от CSRF-атак.
Расширения jQuery
Библиотека jQuery получила свое широкое распространение и огромную популярность не только за свои возможности в работе с DOM-моделью документа и Ajax. В большой степени популярности jQuery способствовало сообщество разработчиков, которые создавали и создают расширения к jQuery. Простота процесса создания плагинов к этой библиотеке послужила бурному росту числа расширений функционала jQuery. На текущий момент уже существует несколько тысяч всевозможных плагинов, которые помогают решать полный спектр задач на стороне клиента: от упрощения работы с данными до реализации богатых визуальных эффектов.
Существуют плагины jQuery и для упрощения работы с Ajax. Найти их можно по адресу http://plugins.jquery.com/project/Plugins/category/47, где на момент написания книги таких плагинов было представлено 182 штуки. В табл. 7.3 перечислены некоторые из них.
Выбор между ASP.NET Ajax и jQuery
Перед разработчиками проектов на базе ASP.NET MVC может встать вопрос: с помощью чего реализовывать работу с Ajax-запросами при разработке клиентской части проекта. И jQuery и ASP.NET Ajax выполняют схожие функции, хотя различаются в подходах. Ответ на этот вопрос зависит от требований, которые разработчики предъявляют к проекту. Рассмотрим некоторые из них по порядку.
□ Расширяемость. Безусловным лидером в плане расширяемости является jQuery, к которой написано тысячи плагинов, расширяющих ее функциональность. Более того, написание своего плагина не представляет сложности, и разработчик всегда может расширить функциональность jQuery для собственных нужд.
□ Сложность. Предполагается, что для работы с jQuery требуются навыки JavaScript-разработки и знание принципов работы самой библиотеки. С другой стороны, ASP.NET Ajax предлагает решение задач, связанных с Ajax-запросами декларативным путем, знакомым каждому разработчику ASP.NET.
□ Перспективы. Используя jQuery, разработчик получает не только механизм управления Ajax-запросами, но и богатый функционал по работе с DOM-моделью. С помощью jQuery разработчик может производить очень быстрые и оптимизированные процедуры поиска, модификации, удаления и добавления элементов DOM. jQuery позволяет оперировать запросами с помощью мощных селекторов, основанных на синтаксисе селекторов CSS3. Это дает в руки разработчика мощный инструмент по быстрейшему доступу к любому набору элементов DOM-страницы на стороне клиента. С другой стороны, ASP.NET Ajax продолжает развиваться, и в версии 4.0 разработчиков ждет масса нововведений, которые позволят работать с данными на базе шаблонов, введут связывание данных и даже контексты данных. Эти высокоуровневые абстракции в перспективе могут значительно облегчить жизнь разработчика.
□ Затратность. Использование любой JavaScript-библиотеки означает дополнительные расходы на количество пересылаемой информации от сервера клиенту. С применением GZip-сжатия на стороне сервера размер передаваемых данных при использовании библиотеки jQuery составляет около двадцати килобайт. С применением функционала ASP.NET Ajax это число может увеличиться до двух раз. Но при расчете затратности необходимо учитывать потенциальное увеличение размера JavaScript-файлов при использовании сторонних или собственных плагинов к jQuery. Кроме того, в перспективе ASP.NET Ajax получит механизм гибкого контроля над размером JavaScript-кода, когда разработчик сможет указать, какие части функционала следует использовать и отсылать клиенту, что значительно уменьшит размер пересылаемых данных.
В идеале, проект на базе ASP.NET MVC может получить приемущества обеих библиотек, если использовать их вместе. Но на практике требования к проекту могут содержать такие условия, когда разработчику приходится выбирать. В таком случае выбор приходится делать на основании рассмотренных ранее условий. Однако если ваш проект не содержит ограничений, и вы можете позволить себе использование нескольких JavaScript-файлов, то авторы книги рекомендуют вам применять обе библиотеки для получения выгоды от разного функционала, которые они предлагают.
Заключение
В этой главе мы рассмотрели технологию Ajax, историю ее возникновения и значение этой технологии при построении веб-приложений в наше время. Мы подробно рассмотрели пару механизмов, которые содержатся в MVC Framework и которые позволяют работать с Ajax – это ASP.NET Ajax и jQuery. Нами были описаны функции, методы и структуры, с помощью которых работают эти механизмы. В завершение главы мы рассмотрели несколько примеров использования ASP.NET Ajax и jQuery для решения задач и привели советы по применению Ajax на практике.
Технология Ajax – это современная технология, которая все более широко распространяется в Интернете. Возникает все больше крупных и мелких вебпроектов, которые используют Ajax в той или иной мере. Многие старые проекты при обновлении также начинают использовать Ajax. В связи с этим понимание и умение использовать технологию на практике – это важное условие построения современного веб-сайта в наше время. И как мы показали в этой главе, MVC Framework предоставляет все возможности для работы с Ajax и поддерживает разработчика удобными инструментами.
ГЛАВА 8
Тестирование веб-приложений
В главах 1 и 2 книги было особо отмечено, что простота автоматизированного тестирования является одним из значительных преимуществ MVC Framework над WebForms. Пришло время рассмотреть более детально процесс автоматического тестирования веб-приложений, созданных на базе MVC Framwork.
В этой главе мы воспользуемся популярным решением с открытым кодом для создания автоматических тестов – NUnit, которое стало стандартом "де-факто" для многих команд веб-разработчиков на платформе Microsoft .NET.
Установка и настройка NUnit
Для начала необходимо загрузить и установить оснастку тестирования NUnit (http://www.nunit.org/?p=download). Затем установить шаблоны проектов тестирования (http://tinyurl.com/nunit-template), для этого нужно загрузить архив NUnit Test Templates, скопировать содержимое директории CSharp в директорию DocumentsVisual Studio 2008TemplatesProjectTemplatesVisual C# (аналогично для директории Visual Basic, если вы используете язык Visual Basic), после чего загрузить данные из REG-файла в реестр для регистрации шаблона NUnit в мастере создания проектов ASP.NET MVC Framework.
Когда вы завершите процедуры установки NUnit и шаблонов проектов, при создании нового проекта ASP.NET MVC Framework появится возможность создать проект для тестирования с использованием NUnit (рис. 8.1).
После создания проекта вместе с проектом веб-приложения будет создан проект библиотеки классов, являющийся основной сборкой для тестирования веб-приложения, представленный на рис. 8.2.
Рис. 8.2. Проект тестирования веб-приложения
В случае если необходимо создать проект тестирования для уже существующего проекта, достаточно добавить в решение проект библиотеки классов, добавить в него ссылку на тестируемый проект и ссылку на сборку nunit.framework.dll, находящуюся в директории bin в директории установки NUnit, и создать тесты так, как будет показано далее в этой главе.
Создание и выполнение тестов
Набор простейших тестов, проверяющий корректность работы контроллера Home из шаблона веб-приложения, приведен в листинге 8.1.
Листинг 8.1. Тесты контроллера Ноше
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web.Mvc;
using NUnit.Framework;
using MvcTestApp;
using MvcTestApp.Controllers;
namespace MvcTestApp.Tests.Tests.Controllers
{
[TestFixture]
public class HomeControllerTest
{
[Test]
public void Index()
{
HomeController controller = new HomeController();
ViewResult result = controller.Index() as ViewResult;
ViewDataDictionary viewData = result.ViewData;
Assert.AreEqual("Welcome to ASP.NET MVC!",
viewData["Message"]);
}
[Test]
public void About()
{
HomeController controller = new HomeController();
ViewResult result = controller.About() as ViewResult; Assert.IsNotNull(result);
}
}
}
Тесты представляют собой методы, помеченные атрибутом Test, помещенные в классы, помеченные атрибутом TestFixture. Среда выполнения тестов NUnit находит в сборке с тестами тестирующие методы именно по этим атрибутам.
Структура каждого теста может быть разбита на три основных элемента:
□ подготовка данных и объектов для проведения теста;
□ выполнение действия, результат которого нужно протестировать;
□ проверка результатов выполнения действия.
Рассмотрим тестовый метод Index из листинга 8.1, проверяющий одноименное действие контроллера Home.
Подготовка данных и объектов в этом случае представляет собой только лишь создание экземпляра класса HomeController.
HomeController controller = new HomeController();
Выполнение действия – вызов метода Index у созданного ранее объекта controller, возвращающего результат типа viewResult.
ViewResult result = controller.Index() as ViewResult;
Проверка результата в данном случае заключается в проверке значения, помещенного в коллекцию ViewData с ключом Message с помощью метода класса Assert, используемого для целей отладки и тестирования.
Assert.AreEqual(«Welcome to ASP.NET MVC!», viewData["Message"]);
После того как тесты созданы, сборку, содержащую тесты, нужно скомпилировать и загрузить в графическую оболочку NUnit. Оболочка распознает методы, помеченные атрибутами Test, и выводит их в виде дерева тестов, как это показано на рис. 8.3.
Тесты можно выполнять по одному, либо блоками, относящимися к одному классу, содержащему тестирующие методы, либо все тесты сразу (рис. 8.4).
Теперь представим себе, что вследствие развития проекта результат выполнения метода Index изменился, и в коллекцию ViewData с ключом Message помещается другая строка.
public ActionResult Index()
{
ViewData["Message"] = "Всем привет!";
return View();
}
Достаточно выполнить перекомпиляцию проекта, не закрывая графического интерфейса NUnit, и сборка, содержащая тесты, будет автоматически загружена заново. В результате выполнения соответствующего теста будет
отображено сообщение об ошибке, включающее детальную информацию, а также фрагмент исходного кода теста, сообщивший о невыполнении условий теста (рис. 8.5).
Как видно из приведенного ранее примера, создание самого теста – задача достаточно простая. Далее будет рассмотрен процесс создания более сложного веб-приложения, требующего написания более сложных тестов.
Несколько слов о важности тестирования
На первый взгляд может показаться, что польза от тестов не велика, если само приложение написано грамотно, модификация кода при развитии приложения происходит под строгим контролем, и выполняется ручное тестирование веб-приложения. Однако такое впечатление складывается только на первый взгляд и для несложных проектов. При автивном внесении изменений в проекты с большим объемом кода автоматическое тестирование позволяет не просто существенно сократить время на проверку корректности внесенных изменений, но и гарантировать совместимость компонентов системы. Кроме того, сам факт создания тестов и разработка архитектуры приложения с учетом тестирования существенно влияет на чистоту кода и архитектуры.
Примечание
Особенно важно автоматическое тестирование тех действий контроллеров, которые возвращают данные для последующей обработки в JavaScript-коде на стороне клиента – отладка ошибок, связанных с некорректными данными на стороне клиента, существенно усложняется за счет введения сущности клиента и клиент-серверной отладки и зачастую не может быть эффективно автоматизирована.
*****************************
Хорошим стилем разработки является создание заготовок модульных тестов для всей функциональности приложения в процессе написания кода самого приложения. То есть сразу после создания нового действия контроллера создается соответствующий метод для тестирования этого действия с базовой проверкой на корректность выполнения действия. Далее, следующей итерацией после написания значительного блока функционала является доработка модульных тестов до полного покрытия всех вариантов использования тестируемого кода и возвращаемых данных.
Тесты и MVC Framework
После прочтения предыдущей части главы можно было убедиться, что создание теста логики веб-приложения, построенного на базе MVC Framework, – задача простая. Этот эффект достигается за счет того, что ядро веб-приложения, состоящее из контроллеров и слоя работы с данными (моделей), может быть выделено в независимую от среды сборку и тестироваться вне контекста веб-сервера и без генерации разметки представления. Даже в тех случаях, когда среде выполнения необходимо взаимодействие с объектами, отвечающими за ввод/вывод разметки и запросов, передаваемых между пользователем и сервером, используются абстрактные классы (например, HttpRequestBase), реализация которых может быть подменена в тестовой среде.
