Как выполнить модульное и интеграционное тестирование в стиле BDD в ASP.NET MVC?

Question

Я изучаю управляемую поведением разработку с ASP.NET MVC и, основываясь на посте от Стива Сандерсона, понимаю, что BDD может означать, по крайней мере, следующие типы тестов: отдельные единицы кода и пользовательский интерфейсвзаимодействия.Нечто подобное упоминается в этом посте .Нужны ли мне две разные тестовые среды, если я хочу и модульное, и интеграционное тестирование?

• Репозитории, контроллеры и службы модульного тестирования, использующие контекстную / спецификационную среду, например MSpec.Результаты тестирования с этим будут полезны для команды разработчиков.

• Тестирование полного поведения (интеграция) с использованием заданной / когда / затем фреймворка, такого как SpecFlow с Watin.Результаты этого тестирования будут полезны для моего клиента.

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

Answer 1

Лично я использую SpecFlow для создания специфических тестов (т. Е. «Пользователь создает новую запись компании»), где я иногда (но не всегда) использую Watin. Для тестирования своих репозиториев или классов обслуживания я буду использовать модульные / интеграционные тесты с NUnit. Интеграционные тесты предназначены для тех случаев, когда мне нужно общаться с базой данных во время теста, а для тех случаев, когда я просто запускаю код в тестируемом целевом объекте без внешних взаимодействий.

Я бы сказал, что вам не нужно использовать BDD-фреймворк для тестов без пользовательского интерфейса. Вы можете, если хотите, но здесь нет строгих правил. Если вы собираетесь это сделать, тогда я настоятельно рекомендую создать более одного проекта для ваших тестов. Хорошая идея - разделять их на части, а не смешивать все тесты в одном проекте. Вы могли бы назвать их:

MyProject.Tests.Features <- для BDD Тесты SpecFlow. </p>

MyProject.Tests.Integration <- Для тесты, которые получают доступ к внешний ресурс, т.е. база данных. </p>

MyProject.Tests.Unit

Если вы не хотите использовать две инфраструктуры BDD, вы все равно можете использовать MSTest / NUnit в режиме BDD. Например, эта статья блога описывает хорошее соглашение об именах, которое близко к BDD, но нацелено на модульные тесты MSTest / NUnit. Вы можете использовать это для ваших тестов не SpecFlow, когда вы тестируете такие вещи, как репозитории.

Итак, вам не нужно использовать SpecFlow и MSpec при тестировании, но если вы это сделаете, то я рекомендую отдельные тестовые проекты.

Answer 2

Я в целом согласен с тем, что написал Джейсон.

Возможно, вы захотите разделить свои спецификации на две категории: тестирование системы / интеграции и тесты на уровне модулей. Вы можете описать обе категории с любой средой, но имейте в виду, что подходы только к коду (NUnit, MSpec и т. Д.) Требуют, чтобы бизнес-аналитик был способен писать на C #. SpecFlow / Gherkin может быть лучшим подходом, если вы хотите привлечь аналитиков и пользователей к написанию спецификаций. Поскольку синтаксис и правила (данные, когда, потом) просты для понимания, а написание спецификаций с точки зрения пользователя легко записать после небольшого обучения. Это все о преодолении разрыва в общении и о том, что пользователи помогают вашей команде сформировать повсеместный язык вашего домена.

Я рекомендую, чтобы спецификации работали как снаружи, так и снаружи. Вы можете начать со спецификации SpecFlow «снаружи», написанной пользователем / аналитиком / владельцем продукта, и перейти от «нереализованного» к «зеленому» написанию реального кода. Код, поддерживающий эту функцию, разработан с использованием TDD с более технически ориентированной средой, такой как MSpec (часть «наизнанку»).

Вот репозиторий, который использует MSpec для модульных и интеграционных тестов: https://github.com/agross/duplicatefinder.