Asp.net mvc framework
Шрифт:
маршрутизации и создает маршруты, необходимые для последующего тестирования:
[TestFixtureSetUp]
public void SetUp
{
MvcApplication.RegisterRoutes(RouteTable.Routes);
}
[TestFixtureTearDown]
public void TearDown
{
RouteTable.Routes.Clear;
}
Обратите
Скомпилируем проект и запустим тест еще раз. На этот раз тест пройден (рис. 6.9).
Для интереса вы можете теперь попробовать модифицировать маршрут Default так, чтобы наш тест перестал работать, например, можно переименовать название действия по умолчанию с Index на Index2. После этого тест будет провален.
Добавим тест для проверки маршрута под названием Product, в нем маршрут определяется простым шаблоном без участия имени действия:
[Test]
public void TestProduct
{
"~/Product/750".Route
.ShouldMapTo<ProductController>(x => x.GetById(750));
}
Добавим еще один тест, на этот раз для проверки игнорирования маршрута для AXD-запросов:
[Test]
public void TestIgnoreAxd
{
"~/someroutetoigonre.axd".ShouldBeIgnored;
}
Запустите тесты и убедитесь, что они пройдены. Обратите внимание на используемый метод расширения ShouldBeIgnored, который предназначен как раз для тестирования игнорирования маршрутов.
Последний наш тест будет направлен на проверку ограничений маршрута. Для тестирования маршрута ProductList определим два следующих теста:
[Test]
public void TestProductListValidYear
{
"~/ProductList/2009".Route
.ShouldMapTo<ProductController>(x => x.List(2009));
}
[Test]
public void TestProductListInvalidYear
{
Assert.AreNotEqual("~/ProductList/1800".Route.Values["controller"],
"Product");
}
Первый тест TestProductListValidYear производит знакомые нам действия, при правильном значении параметра year, ограничение не должно действовать и маршрут должен быть сопоставлен контроллеру Product и действию List. Второй тест TestProductListInvalidYear, наоборот, проверяет поведение маршрута при неверном с точки зрения ограничения параметре year (он должен быть более или равен 1900). Для того чтобы протестировать этот момент, сравниваются имя сопоставленного контроллера и имя контроллера Product. Для успешного прохождения теста они не должны быть равны. Теперь, если убрать ограничение из маршрута, тест будет провален.
После написания всех тестов и запуска NUnit мы должны получить следующую картину успешного прохождения всех тестов (рис. 6.10).
В листинге 6.3 приведен код перечисленных ранее тестов для тех, кто использует тестирование на базе встроенного в Visual Studio инструмента MSTest.
Различий минимум и все они касаются именования атрибутов, которое в NUnit отличается от MSTest.Листинг 6.3. Тестирование с помощью MSTest
namespace Routing
{
using System.Web.Routing;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using MvcContrib.TestHelper; using Routing.Controllers;
[TestClass]
public class TestRoutesMSTest
{
[TestMethod]
public void TestSimpleRoute
{
"~/".Route.ShouldMapTo<HomeController>(x => x.Index);
}
[TestInitialize]
public void SetUp
{
MvcApplication.RegisterRoutes(RouteTable.Routes);
}
[TestCleanup]
public void TearDown
{
RouteTable.Routes.Clear;
}
[TestMethod]
public void TestProduct
{
"~/Product/750".Route
.ShouldMapTo<ProductController>(x => x.GetById(750));
}
[TestMethod]
public void TestIgnoreAxd
{
"~/someroutetoigonre.axd".ShouldBeIgnored;
}
[TestMethod]
public void TestProductListValidYear
{
"~/ProductList/2009".Route
.ShouldMapTo<ProductController>(x => x.List(2009));
[TestMethod]
public void TestProductListInvalidYear
{
Assert.AreNotEqual("~/ProductList/1800".Route
.Values["controller"], "Product");
}
}
}
Утилита ASP.NET Routing Debugger
Для тестирования и проверки правильности создания маршрутов в вашем приложении может пригодиться небольшой инструмент от разработчиков MVC Framework. Данный инструмент позволяет в режиме отладки проверить все зарегистрированные маршруты на работоспособность. Кроме того, этот инструмент поможет посмотреть на то, как и в каком порядке реагируют ваши маршруты на запросы с различными адресами URL.
Примечание
Инструмент ASP.NET Routing Debugger доступен для скачивания по адресуrl-routing-debugger.aspx.
*****************************
Для работы с Routing Debugger необходимо добавить в проект ссылку на сборку RouteDebug.dll и в файле Global.asax добавить одну строку кода в методе Application_Start так, как показано в следующем фрагменте:
protected void Application_Start
{
RegisterRoutes(RouteTable.Routes);
RouteDebug.RouteDebugger.RewriteRoutesForTesting(RouteTable.Routes);
}
После этого, запущенный проект вместо ожидаемой страницы выведет специальную страницу с отчетом о зарегистрированных в проекте маршрутах и их параметрах (рис. 6.11).
ASP.NET Routing Debugger может быть полезен, когда ваш проект содержит массу определенных маршрутов. В таком случае вы получаете наглядный инструмент, который покажет вам порядок и параметры маршрутов, и их реакцию на любой запрос. Используя Routing Debugger, вам не придется долго ломать голову над вопросом: "Почему на этот запрос вызывается этот маршрут?"