Запуск CodeContracts на Visual Studio Team Services

Запуск CodeContracts на Visual Studio Team Services

апреля 21, 2016   C#, Code Contracts,

Этот пост появился не из ниоткуда. Однажды, я, активно использующий CodeContracts, все таки перевез свой блог (тот самый, который вы читаете) на Continuous Integration сервер. Мой выбор пал на Visual Studio Team Services. Ничего не предвещало беды до тех пор, пока безупречно выполняющиеся на моей локальной машине тесты проекта не стали падать с ужасающими ошибками при попытке их запуска на VSTS.

В результате небольшого проведенного расследования, удалось выяснить причину ошибок - предусловия библиотеки CodeContracts, а именно предусловия с заданным типом исключением Contract.Requires<TException>. Дело в том, что при использовании предусловий с заданным типом исключения, сборка не просто может, а должна быть переписана с помощью утилиты ccrewrite.

Разбираемся в причинах

Прежде всего найдем агента, выполняющего сборку на сервере <Ваш VSTS аккаунт>.visualstudio.com/_admin/_AgentPool: в списке его системных переменных нет упоминания CodeContracts

Как следствие, получаемая сборка при построении не подвергается переписыванию утилитой CodeContracts ccrewrite, поставляемой при установке CodeContracts. Значит, нужно установить CodeContracts на CI сервер, выполняющий сборку. Однако, как установить CodeContracts на неподконтрольную разработчику машину?

Создание локальной копии CodeContracts

Предоставим необходимые утилиты для работы CodeContracts рядом с исходными кодами через систему контроля версий По соглашению, все дополнительные утилиты будем располагать в директории Tools корня репозитория: Скопируйте содержимое установленных CodeContracts на вашей машине (по умолчанию C:\Program Files (x86)\Microsoft\Contracts) в директорию проекта Tools/CodeContracts.

Для работы CodeContracts на VSTS не обязательно копировать все содержимое установленных CodeContracts. Достаточно лишь утилит в каталоге Bin, файлов MsBuild для используемой версии и каталога Languages, однако, я предпочитаю иметь полноценную копию CodeContracts в репозитории с лицензией, примерами и документацией.

Пришла пора сделать коммит, включающий локальную копию CodeContracts, на удаленный сервер:

git add Tools/CodeContracts
git commit -m "CodeContracts"
git push

Прежде чем переходить к дальнейшим действиям, проверьте, что все содержимое CodeContracts было скопировано на сервер. Я практически уверен, что в удаленном репозитории отсутствуют файлы директории Tools/CodeContracts/Bin.

Если это так, добавьте в конец файла .gitignore строку !Tools/CodeContracts/Bin. Добавьте в индекс файлы этой директории и повторите коммит, на этот раз содержимое каталога должно успешно скопироваться на удаленный репозиторий.

Дело в том, что файл .gitignore, создаваемый Visual Studio по умолчанию, содержит исключение для каталога Bin, обычно содержащем результаты билдов, которым не место в системе контроля версий. Но в данном случае в этом каталоге содержатся необходимые для сборки утилиты, поэтому строкой !Tools/CodeContracts/Bin задается исключение из общего правила.

В результате удается в каком-то смысле установить CodeContracts на VSTS в виде локальной утилиты.

Дополнительная настройка

Если вы попробуете собрать сборку, результат будет, внезапно, абсолютно тем же самым - ошибка построения, Действительно, если бы CodeContracts были установлены "официально", инсталлятор CodeContracts добавил бы дополнительный шаг сборки, заключающийся в итоговом переписывании сборки утилитой ccrewrite, в процесс построения приложения. Поэтому придется добавлять шаг переписывания сборки через ccrewrite вручную.

Все действия, которые выполняет CodeContracts при сборке проектов описаны в файле Tools/CodeContracts/MsBuild/<Номер версии>/Microsoft.CodeContracts.targets Достаточно импортировать этот файл в файл файлы ваших проектов и CodeContracts наконец-то будут работать на VSTS. Файл проекта .csproj по сути - обычный xml файл, поэтому его легко можно изменить в вашем любимом текстовом редакторе. Добавьте перед закрывающим </Project> тегом строку следующего содержания:

<Import Project="$(SolutionDir)\Tools\CodeContracts\MSBuild\v$(MSBuildToolsVersion)\Microsoft.CodeContracts.targets" />

Наконец, нужно не забыть указать путь к локальной версии CodeContracts, поместив перед строками импорта установку переменных окружения:

<PropertyGroup>
  <CodeContractsInstallDir>$(SolutionDir)\Tools\CodeContracts\</CodeContractsInstallDir>
  <DontImportCodeContracts>True</DontImportCodeContracts>
</PropertyGroup>

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

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

Сохраните изменения в репозитории, и выполните построение сборки, результаты которого должны вас обрадовать:

Подводя итоги

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

1. Скопировать на удаленный репозиторий все необходимые для работы файлы (для данного случая - каталог с установленными CodeContracts);
2. Настроить файлы проектов: установка переменных окружения, добавление шагов сборки и т.п. (для CodeContracts - установка переменных окружения CodeContractsInstallDir и DontImportCodeContracts).

Признаюсь, я потратил половину своего свободного выходного для того, чтобы подружить CodeContracts и VSTS. Надеюсь, что описанный мною способ сможет помочь кому-либо сохранить свое время, и вдобавок не разочароваться ни в CodeContracts, ни в VSTS, ни в CI.

Читать

"Мутация" посетителя и dynamic

"Мутация" посетителя и dynamic

марта 15, 2016   Шаблон проектирования, C#,

Мы не можем игнорировать особенности окружающей нас инфрастуктуры, оказывающей влияние на, казалось бы, незыблемые паттерны проектирования, описанные более 20 лет назад и несомненно ставшими классическими. Возможности, предоставляемые платформой .NET, могут видоизменять и упрощать реализацию паттернов проектирования. Вспомните, как паттерн наблюдатель среди .NET программистов стал неразрывно связан с понятием событий, но в этом посте я хочу рассказать о другом паттерне, чрезвычайно полезном для решения некоторых задач (к примеру, обход синтаксического дерева) - посетителе, открывающемся с другой стороны благодаря новой в .NET 4 DLR и ключевому слову dynamic.

Классический посетитель

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

// Интерфейс посетителя
interface IFigureVisitor
{
 void Visit(Pawn pawn);

 void Visit(Knight knight);

 void Visit(Bishop bishop);
 ...
}

// Базовый класс для всех фигур. 
// Имеет метод Accept, необходимый для реализации посетителя
abstract class Figure 
{
 public abstract void Accept(IFigureVisitor visitor);
 ...
}

class Pawn : Figure
{
 public override void Accept(IFigureVisitor visitor) => visitor.Visit(this);
}

class Knight : Figure
{
 public override void Accept(IFigureVisitor visitor) => visitor.Visit(this);
}

class Bishop : Figure
{
 public override void Accept(IFigureVisitor visitor) => visitor.Visit(this);
}

// Использование:
// Во первых, реализация интерфейса посетителя,
сlass FigureVisitor : IFigureVisitor
{
 public void Visit(Pawn pawn) { ... }
 
 public void Visit(Knight knight) { ... }
 
 public void Visit(Bishop bishop) { ... }
}

// Во вторых, собственно, его использование
class ClassicVisitor
{
 public void Visit(IEnumerable<Figure> figures)
 {
  var visitor = new FigureVisitor();
  
  foreach (var figure in figures)
   figure.Accept(visitor);
 }
}

Ничего страшного, если вы не знакомы с новым C# 6.0 синтаксисом описания метода через лямбду void Accept(IFigureVisitor visitor) => visitor.Visit(this); - при первом знакомстве можно считать их просто удобным сокращением однострочных методов void Accept(IFigureVisitor visitor) { visitor.Visit(this); }

Dynamic посетитель

А сейчас предлагаю посмотреть на иной подход с использованием ключевого слова dynamic: cуть подхода заключается в том, что решение о вызове необходимого метода посетителя производится не самим объектом в виртуальном методе Accept, а внешним кодом, который приминает решение о выборе нужного метода посетителя в зависимости от типа объекта. Как следствие, отпадает необходимость наличия в иерархии типов метода Accept, что позволяет использовать такую версию посетителя в иерархиях классов (к примеру, XElement), не предоставляющих метод Accept.

// Базовый класс для всех фигур
// Теперь от иерархии не требуется наличие метода Accept
abstract class Figure { ... }

class Pawn : Figure { ... }

class Knight : Figure { ... }

class Bishop : Figure { ... }

// Реализации методов посетителя, которые ранее были в FigureVisitor
class DynamicVisitor
{
 public void Visit(IEnumerable<Figure> figures)
 {
  foreach (dynamic figure in figures)
   Visit(figure);
 }
 
 private void Visit(Pawn pawn) { ... }
 
 private void Visit(Knight knight) { ... }
 
 private void Visit(Bishop bishop) { ... }
}

Безусловно, эту же самую функциональность можно реализовать без dynamic, например, последовательной проверкой типа для каждой фигуры, однако dynamic делает код значительно чище, прячет сложность выбора метода за инфраструктурой DLR.

Предлагаю провести аналогию с виртуальными методами: выбор конкректного метода при вызове определяется типом объекта, хотя при отсутствии поддержки виртуальности и невероятном усердии возможно каждый вызов виртуального метода в программе заменить на код выбора конкретного невиртуального метода в зависимости от типа объекта, но так ведь никто не делает, верно?

Сравнение подходов

Следует иметь в виду, что, как обычно, и бывает в мире программирования, у обоих подходов есть как положительные, так и отрицательные стороны. К примеру, насколько разрушительным станет введение нового типа в иерархию типов? Классический посетитель во время компиляции потребует добавить в интерфейс посетителя новый метод, соответствующий новому добавленному типу. Отлично! Как мне кажется, найти ошибку на этапе компиляции - лучший из возможных исходов. Динамический посетитель в принципе не сможет отловить добавление нового типа во время компиляции из-за позднего связывания вызова методов посетителя. К тому же, во время исполнения, если DLR не сможет найти метод с нужной сигнатурой, она будет вынуждена бросить почти ничего не значащий RuntimeBinderException. Совсем нехорошо, но что поделать? К счастью, можно создать метод, который гарантированно вызовется при отсутвии метода с более подходящей сигнатурой:

class DynamicVisitor
{
 public void Visit(IEnumerable<Figure> figures) 
 { 
  foreach (dynamic figure in figures)
   Visit(figure);
 }
 
 private void Visit(Pawn pawn) { ... }
 
 private void Visit(Knight knight) { ... }
 
 private void Visit(Bishop bishop) { ... }
 
 private void Visit(Figure figure) 
 { 
  /* 
   * Действия по умолчанию, объекты новых типов иерархию попадут сюда, 
   * вместо выброса неприятного исключения 
   */
 }
}

Перейдем к ощутимым плюсам динамического посетителя: благодаря тому, что DLR выбирает наиболее подходящий по сигнатуре метод из всех доступных перегрузок, возможно писать вещи, которые невозможно или чрезвычайно сложно реализовать классическим подходом, но, соглашусь, такой код слишком отдален от классического шаблона:

class DynamicVisitor 
{
 public void Visit(IEnumerable<Figure> blackFigures, IEnumerable<Figure> whiteFigures) 
 { 
  foreach (dynamic blackFigure in blackFigures)
   foreach (dynamic whiteFigure in whiteFigures)
    Visit(blackFigure, whiteFigure);
 }
 
 private void Visit(Pawn pawn, Knight knight) { ... }
 
 private void Visit(Pawn pawn, Pawn pawn) { ... }
 
 private void Visit(Knight knight, Pawn pawn) { ... }
}

Классический посетитель, тем не менее, имеет свои недостатки: что думаете об интерфейсе, который знает и зависит от всех типов иерархии, что по сути создает жесткие зависимости между всеми типами иерархии, или требование метода Accept, отсутствие которого полностью ограничивает применение паттерна, а если код находится во внешней библиотеке, то добавить такой метод не получится никаким способом (если конечно вы не являетесь ее автором)?

В свою очередь, не в пользу dynamic подхода играет производительность: даже без бенчмарков очевидно, что само применение тяжеловесного dynamic для разрешения перегрузки метода не прибавляет производительности вашего приложения. С другой стороны, когда это посетители являлись боттленеком?

Хотя производительность и не является темой статьи, настоятельно рекомендую не говорить о проблемах производительности или утечках памяти без результатов профилирования.

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

Читать

Ошибки использования IsNullOrWhiteSpace

Ошибки использования IsNullOrWhiteSpace

февраля 28, 2016   Перевод, Тестирование, C#,

Перевод статьи Марка Симана The IsNullOrWhiteSpace trap.

Метод string.IsNullOrWhiteSpace, ровно как и string.IsNullOrEmpty поначалу могут казаться полезными утилитными методами. Но на самом деле это не совсем так. В действительности, они заставляют нас думать о равенстве null и пустых строк, что конечно не так.

null - это не пустая строка. null представляет отсутсвие значения.

Всевозможные комбинации пробельных символов в строке, ровно как и пустая строка ("", " ", и т.д.) вполне корректные значения, хотя, в большинстве случаев, они не представляют для нас большого интереса.

Пример: нормализованный поиск

Представьте, что вы написали простой алгоритм для сервиса поиска музыки. Одна из задач, которую мы попытаемся решить, заключается в том, что пользователь при поиске может использовать различные комбинации строчных и заглавных символов при вводе, а также, к примеру, вводить имя исполнителя перед названием композиции, либо наоборот. Чтобы сделать систему поиска максимально эффективной, есть смысл закэшировать популярные поисковые запросы, однако перед этим придется преобразовать каждый поисковый запрос в его нормализованную форму.

Чтобы не усложнять решение, примем нормализованную форму запроса как строку в верхнем регистре с расположением слов запроса в алфавитном порядке. Не составит труда написать, скажем, пять тестовых сценариев, представленных параметризированными тестами:

[Theory]
[InlineData("Seven Lions Polarized"  , "LIONS POLARIZED SEVEN"  )]
[InlineData("seven lions polarized"  , "LIONS POLARIZED SEVEN"  )]
[InlineData("Polarized seven lions"  , "LIONS POLARIZED SEVEN"  )]
[InlineData("Au5 Crystal Mathematics", "AU5 CRYSTAL MATHEMATICS")]
[InlineData("crystal mathematics au5", "AU5 CRYSTAL MATHEMATICS")]
public void CanonicalizeReturnsCorrectResult(
    string searchTerm,
    string expected)
{
    string actual = SearchTerm.Canonicalize(searchTerm);
    Assert.Equal(expected, actual);
}

Возможная реализация функции нормализации:

public static string Canonicalize(string searchTerm)
{
    return searchTerm
        .Split(new[] { ' ' })
        .Select(x => x.ToUpper())
        .OrderBy(x => x)
        .Aggregate((x, y) => x + " " + y);
}

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

Продолжим: сделаем реализацию надежнее

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

[InlineData("Seven  Lions   Polarized", "LIONS POLARIZED SEVEN")]
[InlineData(" Seven  Lions Polarized ", "LIONS POLARIZED SEVEN")]

Новые тесты не проходят, потому что функция неверно обрабатывает несколько идущих подряд пробелов.

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

public static string Canonicalize(string searchTerm)
{
    return searchTerm
        .Split(new[] { ' ' }, StringSplitOptions.RemoveEmptyEntries)
        .Select(x => x.ToUpper())
        .OrderBy(x => x)
        .Aggregate((x, y) => x + " " + y);
}

Единственное отличие в добавлении флага StringSplitOptions.RemoveEmptyEntries в качестве второго аргумента метода Split.

Тестирование на Null

Несмотря на то, что все тесты успешено проходят, может у метода есть еще несколько невыявленных проблем?

Есть, по крайней мере, одна: если searchTerm каким-либо образом будет неопределенным, метод сгенерирует NullReferenceException. Действительно, ведь нельзя же вызвать метод Split на пустой ссылке.

Чтобы проверить все пути исполнения кода, мы должны протестировать единственный параметр метода на null, ожидая выброс исключения:

[Fact]
public void CanonicalizeNullThrows()
{
    Assert.Throws<ArgumentNullException>(
        () => SearchTerm.Canonicalize(null));
}

В таком случае, null принимается как недопустимое значение, и я согласен. Поиск для null (воспринимайте его как отстутсвие значения) бессмысленнен, это скорее сигнализирует об ошибке в вызывающем метод коде.

Я часто вижу, как программисты раз за разом выполняют проверку наподобие такой:

public static string Canonicalize(string searchTerm)
{
    if (string.IsNullOrWhiteSpace(searchTerm))
        throw new ArgumentNullException("searchTerm");
 
    return searchTerm
        .Split(new[] { ' ' }, StringSplitOptions.RemoveEmptyEntries)
        .Select(x => x.ToUpper())
        .OrderBy(x => x)
        .Aggregate((x, y) => x + " " + y);
}

Обратите внимание на использование IsNullOrWhiteSpace. Конечно, все тесты проходят, но все же это неправильно по нескольким причинам.

Проблемы с IsNullOrWhiteSpace

Во-первых, использование IsNullOrWhiteSpace таким образом отдает вызывающему коду ложные сообщения об ошибке. Для примера, если передать методу пустую строку "" (не null) как параметр searchTerm, метод выбросит NullReferenceException!. Это в корне неверно: исключение рассказывает о пустой ссылке, когда это не так (пустая строка не null).

Конечно, можно изменить тип исключения на ArgumentException и добавить к нему поясняющее сообщение:

if (string.IsNullOrWhiteSpace(searchTerm))
    throw new ArgumentException("Empty or null.", "searchTerm");

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

Наконец, разве есть причины не допускать пустую строку как допустимый арумент?

Самое время перейти к заключительным доработкам метода, работающем с пустыми и пробельными строками, как обычными строками. Сначала добавим пару-тройку тестов на такой случай:

[InlineData("", "")]
[InlineData(" ", "")]
[InlineData("  ", "")]

Эти тесты завершатся неудачей из-за использования IsNullOrWhiteSpace, но это легко исправить.

Итоговая версия метода нормализации:

public static string Canonicalize(string searchTerm)
{
    if (searchTerm == null)
        throw new ArgumentNullException("searchTerm");
 
    return searchTerm
        .Split(new[] { ' ' }, StringSplitOptions.RemoveEmptyEntries)
        .Select(x => x.ToUpper())
        .OrderBy(x => x)
        .Aggregate("", (x, y) => x + " " + y)
        .Trim();
}

Во первых, защитное условие инициирует выброс исключения только при передаче null в качестве аргумента. Все значения, отличные от пустой ссылки корректны. Во вторых, метод использует одну из перегрузок linq метода Aggregate, принимающую пустую строку как начальное значение, используемое для выполнения операции свертки. И наконец, в третьих, завершающий вызов Trim гарантирует, что в результирующей строке не останется либо предшествующих, либо завершающих пробелов.

Суть IsNullOrWhiteSpace

По сути, проблема string.IsNullOrEmpty и string.IsNullOrWhiteSpace в том, что они создают впечатление равентсва null и пустых строк, что не так: пустые строки это самые настоящие строки, с которыми в подавляющем большинстве случаев можно работать также, как и с любыми другими.

Если вы уверены, в пустая строка есть эквивалент null, вы будете выбрасывать их в корзину к "неправильным" данным. Если взглянуть на предусловия классов, методов или функций, можно заметить, что пустые строки, в большинстве случаев, прекрасно укладываются в их область допустимых значений. Так зачем же их отклонять? Такой подход лишь превносит в код ненужную сложность и делает его сложнее для использования.

Если рассуждать в терминах тестирования, по моему опыту, null и пустые строки очень редко относится к одному классу эквивалентности. Поэтому рассматривать их эквивалентно не совсем верно.

Методы string.IsNullOrWhiteSpace и string.IsNullOrEmpty, которые подразумевают равенство null, пустых строк и строк пробельных символов неправильно очерчивают граничные условия в ваших приложениях. Поэтому, будьте внимательны при их использовании.

Читать

Тестирование маршрутов ASP.NET MVC приложения

Тестирование маршрутов ASP.NET MVC приложения

февраля 23, 2016   Тестирование, ASP.NET MVC, C#,

Приветствую! Этим постом я открываю серию статей по тестированию различных компонентов приложений. Логика программы, пользовательский интерфейс, база данных - все это входящие в состав практически любой программы компоненты, подход к созданию которых диаметрально отличается друг от друга. Что и говорить - эти компоненты, или как их чаще называют - слои приложения, даже могут создаваться разными группами разработчиков. Совершенно естественно, что подход к тестированию таких непохожих частей программы не может быть абсолютно унифицирован.

Предлагаю начать обсуждение с относительно простой для тестирования системы маршрутизации ASP.NET MVC приложения.

Даже если в вашем проекте не применяются технологии модульного тестирования, тесты маршрутов могут служить неплохим стартом для написания тестов, так же как сами маршруты представляют начало обработки запроса в конвейере MVC приложения. К тому же для маршрутов невероятно важно понятие отсутсвия регрессии - неверное изменение или удаление маршрутов уже существующей схемы маршрутизации в работающем приложении, или ошибки в схеме могут значительно понизить посещаемость и уважение сайта из-за битых ссылок, ведущих в никуда. Вдобавок, в процессе развития приложения, маршруты стремятся переплестись в сложнопонимаемые сети, приводящие к параличу изменений (любые, даже самые незначительные, изменения сопровождаются огромным стрессом из-за страха что-либо сломать), и именно наличие тестов на систему маршрутизации способно облегчить ее понимание и развитие.

Как вы убедитесь, в итоге получаются очень простые и понятные тесты, визуально состоящие только из assert секции. Но как же этого добиться?

Обзор возможности для тестирования

Для тестирования маршрутов требуется не столь многое: мок HttpContextBase, мок HttpRequestBase, и, конечно, не стоит забывать о моке HttpResponseBase для тестирования исходящих Uri. Необходимые перегрузки членов для этих контекстов можно найти в github репозитории проекта, которому посвящена эта статья. Создание моков с одной стороны позволяет глубже понять инфраструктуру MVC фреймворка, но все это не укладывается в обещанную простоту тестов, к тому же такое решение не подчиняется принципу DRY, из-за постоянного повторения одного и того же кода для создания моков в ваших проектах.

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

Предварительная инициализация

Практически каждая библиотека, или, тем более фреймворк, требует некоторой начальной настройки, которые мы называем инициализацией. Большинство тестов, в т.ч. тесты маршрутов, имеют предварительную Arrange секцию. К счастью, для тестов маршрутов Arrange секция не только одинакова для всех тестов, но и занимает одну-единственную строку: инициализация коллекции маршрутов.

public class RoutesTests {
 private readonly RouteCollection routes = new RouteCollection();

 public RoutesConfigTests()
 {
  new RoutesConfig().Configure(routes);
 }
}

В зависимости от используемого фреймворка тестирования метод инициализации размещается в разных местах кода: Для xUnit, который использую я, таким местом инициализации служит конструктор, для NUnit, придется выделить метод Initialize и пометить его аттрибутом SetUpAttribute, или TestInitializeAttrribute для MsTest.

Займемся тестами

Библиотека предлагает два практически равнозначных способа описания маршрутов: через статичесткие методы класса RouteAssert или использование так называемого fluent синтаксиса.

Предлагаю начать написание тестов маршрутов через RouteAssert. Визуально описание маршрутов очень похоже на одну assert секцию, поэтому разобраться в простых примерах не должно составить особого труда:

public void RoutesTest()
{
 // Главная страница сайта
 RouteAssert.HasRoute(routes, "/",
  "Articles", "Show", new { page = 1 });
  
 // Страница статьи блога
 // Конечно, не нужно описывать их все, достаточно одного-двух тестов
 RouteAssert.HasRoute(routes, "/test-mvc-routes", 
  "Article", "Show", new { name = "test-mvc-routes" });
 ...
 
 // Несуществующие маршруты тоже не помешало бы проверить
 RouteAssert.NoRoute(routes, "/test-mvc-routes/more-segment");
}

Обратите внимание, на предварительный слеш и отсутствие имени домена, (ведь маршруты абсолютно независимы от конкретного доменного имени). Посмотрите, как легко читаются тесты: например, первое утверждение RouteAssert.HasRoute(routes, "/", "Articles", "Show", new { page = 1 }); проверяет, что, для коллекции маршрутов routes (напомню, коллекция тестируемых маршрутов задается при инициализации тестов), запрос пользователем страницы "http://your-domain-name/" будет обработан методом действия "Show" контроллера "ArticlesController", вдобавок, методу действия будет передан параметр page со значением 1. Как и в большинстве мест MVC фреймворка указание постфикса "Controller" для контроллеров не требуется.

Гуру тестирования неустанно повторяют правило "Один тест - один ассерт" (не один вызов Assert метода в конце теста, а одна логическая секция Assert, которая без сомнения может содержать несколько Assert утверждений). Но думаю, что в данном случае выделение отдельного метода размером в одну строку не имеет особого практического смысла и лучше группировать несколько тестов маршрутов по обрабатывающему их контроллеру.

Описание тестов во fluent стиле

Используя fluent подход для написания тестов, можно получить, возможно, с какой-то точки зрения, более читабельные тесты. Для этой цели fluent подход использует мощь деревьев выражений для указания цели маршрута. Посмотрите на те же самые тесты, записанные во fluent синтаксисе:

public void RoutesTest()
{
 // Главная страница сайта
 routes.ShouldMap("/")
  .To<ArticlesController>(a => a.Show(1));

 routes.ShouldMap("/test-mvc-routes")
  .To<ArticleController>(a => a.Show("test-mvc-routes"));

 routes.ShouldMap("/test-mvc-routes/more-segment")
  .ToNoRoutes();
}

Здесь выражения вида a => a.Show(1) - не просто анонимный метод (лямбда выражение), а так называемое дерево выражений, которое, грубо говоря, "парсится" библиотекой, в итоге получая те же самые "Article", "Show", new { page = 1 }, как и при использовании RouteAssert подхода, но, согласитесь, гораздо читабельнее.

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

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

Читать