Asp.net mvc framework
Шрифт:
Для того чтобы использовать наш класс, необходимо заполнить таблицы значениями. Сделаем это для определения стандартного маршрута Default так, как представлено на рис. 6.4 и 6.5.
После того как данные внесены в базу данных, можно интегрировать механизм в проект. Для этого следует в global.asax удалить старое определение маршрута Default
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
DatabaseRoutes dbRoutes = new DatabaseRoutes(routes);
dbRoutes.Register;
}
Если вы сделали все правильно, то результатом будет работа вашего проекта на основе маршрута, полученного из базы данных. Теперь, реализовав каким-либо образом доступ к базе данных маршрутов, вы получите возможность предоставить функции редактирования маршрутов администратору без модификации исходных кодов в виде global.asax.
Представленный пример предполагает реализацию хранения только простейших маршрутов. Для хранения данных об ограничениях, данных DataTokens или данных игнорирования маршрутов механизм придется расширить, что не должно составить труда.
Маршрутизация и тестирование
Когда дело касается модульного тестирования механизмов маршрутизации, то определение области тестирования не выглядит очевидным. Что необходимо тестировать? В простейшем случае, когда ваш проект на MVC Framework содержит всего один маршрут Default, определенный по умолчанию, модульное тестирование теряет большую часть смысла. Но в случаях, когда маршрутов в проекте много, повсеместно используется ограничение и игнорирование маршрутов, модульное тестирование обретает широкую область для применения.
Здесь мы на нескольких примерах рассмотрим, как включить в свой проект тесты маршрутов, ограничений и маршрутов игнорирования.
Тестирование определенных разработчиком маршрутов — достаточно простое, но важное дело. Так как маршрутизация — это один из краеугольных механизмов, который осуществляет работу веб-приложения, правильно функционирующие маршруты — важнейшая часть любой системы. Ошибка при переопределении маршрута или добавлении нового маршрута может стоить выхода из строя как отдельного функционала, так и всего сайта.
Для тестирования маршрутов воспользуемся тремя популярными средствами:
? NUnit — альтернативное средство тестирования;
? RhinoMocks — позволяет создавать фальшивые, так называемые, "мок-объекты";
? MvcContrib — содержит функционал, расширяющий возможности MVC Framework, в том числе и в сфере модульного тестирования.
Подготовка инструментов
Для того чтобы использовать инструменты тестирования в своем проекте, необходимо проделать следующие действия. Во-первых, установите пакет тестирования NUnit. Во-вторых, добавьте в проект ссылки на сборки:
MvcContrib.TestHelper.nunit.framework и Rhino.Mocks так, как показано на рис. 6.6.
После этих двух шагов вы готовы для создания модульных тестов механизма маршрутизации. Для тестирования в MvcContrib существует набор специальных методов расширения, которые позволяют
значительно упростить создание тестов. Это метод ShouldMapTo<T>, который позволяет протестировать строку определения маршрута, и метод ShouldBeIgnored, который позволяет протестировать правило игнорирования маршрута.
Создание тестов
Для демонстрации создания модульных тестов первым делом определим набор маршрутов, которые будут подвергнуты тестам. Далее представлен фрагмент кода с определением ряда маршрутов:
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Product",
"Product/{id}",
new { controller = "Product", action = "GetById" }
);
routes.MapRoute("ProductList",
"ProductList/{year}",
new { controller = "Product", action = "List" },
new { year = new YearConstraint }
);
routes.MapRoute(
"Default",
"{controller}/{action}/{id}",
new { controller = "Home", action = "Index", id = "" }
);
Как вы можете видеть, в коде определяется три маршрута: Product, ProductList и маршрут по умолчанию Default. Кроме того, определено стандартное правило игнорирования маршрута для игнорирования запросов к
AXD-ресурсам. Обратите внимание, что маршрут с названием ProductList содержит ограничение для параметра year (ранее в этой главе мы рассматривали это ограничение).
Для определения тестов необходимо создать простой класс, например, представленный во фрагменте:
namespace Routing {
using System.Web.Routing;
using MvcContrib.TestHelper;
using NUnit.Framework;
using Routing.Controllers;
[TestFixture]
public class TestRoutes
{
}
}
Обратите внимание на использование атрибута TestFixture. Это атрибут инструмента NUnit, который позволяет определить класс с набором тестов. Добавим в класс простой тест:
[Test]
public void TestSimpleRoute
{
"~/".Route.ShouldMapTo<HomeController>(x => x.Index);
}
Этот тест направлен на проверку определения маршрута при доступе к сайту по URL без каких-либо параметров или относительных путей. Здесь ожидается, что по умолчанию должен сработать маршрут Default и выполниться действие Index контроллера HomeController.
Для того чтобы запустить наш тест, необходимо скомпилировать проект с тестом и запустить среду NUnit, главное окно которой представлено на рис. 6.7.
C помощью пункта меню File | Open Project добавим в среду сборку нашего проекта тестирования. В моем случае это сборка Routing.dll. После того как сборка загрузится, нажмите кнопку Run для запуска тестов. Как можно убедиться, наш тест не пройден (рис. 6.8).
Для того чтобы тест был пройден, в наш класс модульного тестирования нужно добавить следующий код, который инициализирует механизм