ASP.NET MVC 4 в действии

Джеффри Палермо

Тестирование поведения маршрута

В предыдущем разделе вы видели, как можно случайно нарушить схему маршрутизации приложения, и как использовать Route Debugger для обнаружения возникших проблем во время выполнения. Но можно также писать модульные тесты для роутов, которые в первую очередь будут предотвращать возникновение таких проблем. В этом разделе мы рассмотрим, как тестировать обработку входных роутов, а также генерацию исходящих роутов.

Тестирование входящих роутов

По сравнению с остальной частью ASP.NET MVC Framework, тестирование роутов нельзя назвать легкой или интуитивной работой из-за количества абстрактных классов, для которых необходимо использовать mock-технологию. Чтобы сделать это вручную, потребуется много кода настроек, как показано в следующем листинге.

using System.Web;
using System.Web.Routing;
using NUnit.Framework;
using Rhino.Mocks;
namespace RoutingSample.Tests
{
	[TestFixture]
	public class NotUsingTestHelper
	{
		[Test]
		public void root_matches_home_controller_index_action()
		{
			const string url = "~/";

			var request = MockRepository.GenerateStub<HttpRequestBase>();
			request.Stub(x => x.AppRelativeCurrentExecutionFilePath).Return(url).Repeat.Any();
			request.Stub(x => x.PathInfo).Return(string.Empty).Repeat.Any();

			var context = MockRepository.GenerateStub<HttpContextBase>();
			context.Stub(x => x.Request).Return(request).Repeat.Any();

			RouteTable.Routes.Clear();
			MvcApplication.RegisterRoutes(RouteTable.Routes);

			var routeData = RouteTable.Routes.GetRouteData(context);
			Assert.That(routeData.Values["controller"],
			Is.EqualTo("Home"));
			Assert.That(routeData.Values["action"],
			Is.EqualTo("Index"));
		}
	}
}

Если бы все тесты роутов выглядели так, как показано в листинге 9-11, никто бы даже и не потрудился их тестировать. Специфические заглушки на HttpContextBase и HttpRequestBase тоже не стали удачным решением. Они заглядывали внутрь инструмента Red Gate’s Reflector, чтобы выяснить, для чего использовать mock. Это неправильное поведение для тестируемой платформы!

К счастью, проект MvcContrib включает в себя удобный и быстрый API для тестирования роутов, который значительно упрощает работу. Для начала мы должны установить сборку MvcContrib.TestHelper с помощью команды Install-Package MvcContrib.Mvc3.TestHelper-ci в NuGet Package Manager Console, как показано на рисунке 9-9.

Рисунок 9-9: Установка MvcContrib Test Helper через NuGet

Следующий листинг представляет собой тот же тест, но с использованием расширений MvcContrib для тестирования роутов.

[TestFixtureSetUp]
public void FixtureSetup()
{
	RouteTable.Routes.Clear();
	MvcApplication.RegisterRoutes(RouteTable.Routes);
}
[Test]
public void root_maps_to_home_index()
{
	"~/".ShouldMapTo<HomeController>(x => x.Index());
}

Начнем с регистрации роутов нашего приложения в TestFixtureSetUp с помощью статического метода RegisterRoutes из Global.asax. Фактически сам тест выполняется методами расширения и лямбда-выражениями. Внутри тестового вспомогательного метода MvcContrib есть метод расширения для класса string, который создает экземпляры RouteData на основе параметров URL. Класс RouteData имеет метод расширения для подтверждения того, что значения роута соответствуют контроллеру и действию.

В листинге 9-12 можно увидеть, что имя контроллера выводится из аргумента универсального типа в вызове метода ShouldMapTo<TController>(). Действие тогда определяется с помощью лямбда-выражения. Выражение разбивается так, чтобы получить вызов метода (действия) и любые аргументы, которые будут ему переданы. Аргументы сопоставляются со значениями роута. Более подробную информацию об этих расширениях для тестирования роутов можно найти на сайте MvcContrib http://mvccontrib.org.

Теперь пришло время применить их к правилам маршрутизации нашего магазина и убедиться, что мы охватили все необходимые случаи.

using System.Web.Routing;
using MvcContrib.TestHelper;
using NUnit.Framework;
using RoutingSample.Controllers;
namespace RoutingSample.Tests
{
	[TestFixture]
	public class UsingTestHelper
	{
		[TestFixtureSetUp]
		public void FixtureSetup()
		{
			RouteTable.Routes.Clear();
			MvcApplication.RegisterRoutes(RouteTable.Routes);
		}
		[Test]
		public void root_maps_to_home_index()
		{
			"~/".ShouldMapTo<HomeController>(x => x.Index());
		}
		[Test]
		public void privacy_should_map_to_home_privacy()
		{
			"~/privacy".ShouldMapTo<HomeController>(x => x.Privacy());
		}
		[Test]
		public void products_should_map_to_catalog_index()
		{
			"~/products".ShouldMapTo<CatalogController>(x => x.Index());
		}
		[Test]
		public void product_code_url()
		{
			"~/products/product-1".ShouldMapTo<CatalogController>(x => x.Show("product-1"));
		}
		[Test]
		public void product_buy_url()
		{
			"~/products/product-1/buy".ShouldMapTo<CatalogController>(x => x.Buy("product-1"));
		}
		[Test]
		public void basket_should_map_to_catalog_basket()
		{
			"~/basket".ShouldMapTo<CatalogController>(x => x.Basket());
		}
		[Test]
		public void checkout_should_map_to_catalog_checkout()
		{
			"~/checkout".ShouldMapTo<CatalogController>(x => x.CheckOut());
		}
		[Test]
		public void _404_should_map_to_error_notfound()
		{
			"~/404".ShouldMapTo<ErrorController>(x => x.NotFound());
		}
		[Test]
		public void ProductsByCategory_MapsToWebFormPage()
		{
			"~/Products/ByCategory".ShouldMapToPage("~/ProductsByCategory.aspx");
		}
	}
}

Каждый из этих простых тестов использует интерфейс тестирования NUnit. Они также используют метод расширения ShouldMapTo<T> из MvcContrib.TestHelper.

Запустив этот пример, мы увидим, что все наши роуты работают нормально. На рис 9-10 показаны результаты в ReSharper test runner (могут выглядеть несколько по-другому, в зависимости от вашей тестируемой платформы и версии программы).

Рисунок 9-10: Результаты тестирования роутов в ReSharper test runner

Вооружившись этими тестами, вы можете свободно изменять правила роутов, не беспокоясь о том, что после этого у вас на сайте перестанут работать ссылки. Представьте себе, что ссылки на товары на Amazon.com неожиданно перестали бы работать из-за опечатки в каком-нибудь правиле роута... Не позволяйте такому случиться с вашим сайтом. Гораздо легче писать автоматизированные тесты для сайта, чем вручную проводить исследовательское тестирование для каждого релиза.

Тестирование исходящих роутов

В тестировании роутов есть один важный аспект, которому мы до сих пор уделяли мало внимания: исходящая маршрутизация. Как было определено ранее, исходящая маршрутизация относится к URL, которые генерируются платформой по данному набору значений роута. Вспомогательные методы для тестирования генерации исходящих роутов также включены в проект MvcContrib и показаны в следующем листинге.

[TestFixtureSetUp]
public void FixtureSetup()
{
	RouteTable.Routes.Clear();
	MvcApplication.RegisterRoutes(RouteTable.Routes);
}
[Test]
public void Generates_products_url()
{
	OutBoundUrl.Of<CatalogController>(x => x.Show("my-product-code"))
		.ShouldMapToUrl("/products/my-product-code");
}

В этом примере мы тестируем роут для страницы товара нашего приложения. С помощью метода OutBoundUrl.Of мы можем убедиться, что при передаче в движок маршрутизации имени контроллера catalog, действия show и товарного кода my-product-code он будет генерировать URL /products/my-product-code.

Теперь, когда мы рассмотрели исчерпывающий пример схем маршрутизации, мы можем начинать создавать роуты для своих собственных приложений и получать удобные, доступные URL. Мы также познакомились с некоторыми полезными расширениями для модульного тестирования, которые помогают гораздо проще тестировать входящие роуты.

Подписаться

или RSS канал: