Можно ли включать символы URL в имя теста MSpec при тестировании маршрутизации?

Как я могу представить следующий сценарий с помощью MSpec?:

Scenario: Navigation to homepage
   When I navigate to /Guestbook
   Then I should be on the guestbook page

SpecFlow упрощает такие вещи, потому что мы можем передавать параметры в наши спецификации:

[When(@"I navigate to (.*)")]
public void WhenINavigateTo(string relativeUrl)
{
}

В MSpec контекст/спецификация происходит от имени класса, поэтому я не могу использовать какие-либо специальные символы (например, используемые в URL-адресе).

То, что я хотел бы достичь, это вывод, например:

Browsing the site, When I navigate to /guestbook
¯ should go to the guestbook page
Browsing the site, When I navigate to /news/article-slug
¯ should go to the news article with matching slug

person Ben Foster    schedule 08.04.2012    source источник


Ответы (2)


На самом деле нет способа использовать специальные символы в контексте или спецификации в MSpec, это никогда не было необходимо раньше. Я думаю, что вы единственный человек, которого я видел, у которого была убедительная причина иметь реальный путь URL в своей спецификации. Обычно вы избегаете этого, но если SEO-специалисты читают ваш отчет о спецификациях, я могу это увидеть. Вы можете попробовать другой инструмент или отправить в MSpec исправление, добавляющее поддержку атрибутов, которые могут переопределять строковое имя контекста или спецификации.

person Aaron Jensen    schedule 16.08.2012

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

Для описания поведения URL и других технических деталей я бы предпочел использовать пример на уровне класса, также известный как модульный тест. MSpec отлично подходит для этого. Например, это описывает класс Navigator, который предоставляет URL-адреса:

Мой класс Navigator должен предоставлять читаемые и запоминающиеся URL-адреса.

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

Затем вы можете выполнить проверку вашего фактического URL-адреса внутри этого примера.

На более высоком уровне попробуйте подумать о сценарии с точки зрения возможностей, которые ваша система предоставляет пользователю. Если я пользователь, какое мне дело до того, что я могу использовать этот конкретный URL-адрес для гостевой книги? Почему я вообще захожу в гостевую книгу? SpecFlow лучше подходит для этого уровня.

Моя гостевая книга должна показать мне, кто вошел в систему

Учитывая, что Keyboard Cat недавно подписал мою гостевую книгу
Когда я захожу в гостевую книгу
, я должен увидеть имя Keyboard Cat в списке.

Теперь вы можете сделать так, чтобы сценарий переходил к гостевой книге, но при этом сохраняйте подробности того, как пользователь переходит к гостевой книге, в шагах сценария. Вы также можете видеть, что сценарий ничего не говорит о том, используете ли вы веб-страницу, приложение Windows, мобильный телефон или физическую книгу — речь идет только о возможностях, которые вы предоставляете. Как правило, сценарии более высокого уровня, подобные этому, легче поддерживать, и они помогут всей вашей команде сосредоточиться на ценности, которую вы предоставляете пользователю.

person Lunivore    schedule 09.04.2012
comment
проблема здесь в том, что он должен быть удобочитаемым, но недостаточно подробным для моих заинтересованных сторон (специалистов по поисковой оптимизации и т. д.). Позволяет ли MSpec переопределить текст утверждения в отчете, как это можно сделать с помощью [Subject]? На самом деле мне нужно включить сгенерированный URL-адрес в отчет. - person Ben Foster; 10.04.2012
comment
Насколько я знаю, нет... но ведь у меня никогда раньше не было заинтересованных лиц, интересующихся моими модульными тестами! Вы пытались вместо этого предоставить им демоверсию? Это может быть более убедительно, чем отчет MSpec... - person Lunivore; 10.04.2012