SpecFlow/BDD для модульных тестов?

Кажется, что в Интернете нет окончательного ответа или набора принципов, которые помогут мне ответить на вопрос. Поэтому я обращаюсь к великим людям на SO, чтобы помочь мне найти ответы или руководящие мысли:)

SpecFlow очень полезен для BDD в .NET. Но когда мы говорим о BDD, мы просто говорим о тестах интеграции/приемочного тестирования, или мы также говорим об модульных тестах - общей замене TDD?

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

Теперь вам..........

EDIT: я забыл упомянуть, что я вижу RSpec в сообществе RoR, который использует синтаксис стиля BDD для модульного тестирования.

Ответ 1

Недавно я начал использовать SpecFlow для моего тестирования BDD, но также я все еще использую тесты модулей и интеграции.

В принципе, я разделяю тесты на отдельные проекты:

функции
Интеграция
Unit

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

Я использую BDD для описания тестов, которые имитируют требования к бизнесу/домену проекта. Например, у меня были бы спецификации для функции генерации счета проекта; или для работы с корзиной покупок. Эти тесты следуют за

Как пользователь, я хочу, чтобы

тип семантики.

Мой совет состоит в том, чтобы разделить ваши тесты на основе ваших потребностей. Не пытайтесь выполнить модульное тестирование с помощью SpecFlow.

Ответ 2

Мы начали использовать Specflow даже для наших модульных тестов.

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

Уверен, что это также можно сделать с помощью стандартных модулей тестирования модулей, но вы не руководствовались так же легко, как мы выяснили, мы используем specflow и синтаксис gherkin.

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

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

Ответ 3

Я рассматриваю это как интеграционное тестирование, которое означает, что он не заменяет ваши дела unit test, написанные как часть вашего процесса TDD. У кого-то будет свое мнение по этому поводу. IMHO unit test case проверяет только методы/функции, и все зависимости должны быть издевательскими и инъецированными. Когда в нем приходит интеграционное тестирование, вы будете вводить реальные зависимости, а не издеваться над ними. Вы можете выполнить одно и то же тестирование интеграции с любой из модулей тестирования модулей, но BDD предоставляет вам более чистый способ объяснения использования тестового теста интеграции на языке, специфичном для домена, который является простым английским языком (или любым локализованным языком).

Та,
Rajeesh

Ответ 4

Я использовал specflow для тестирования BDD в двух разных приложениях хорошего размера. Как только мы работали над изломами условных обозначений предложений, это получилось довольно хорошим. BA и QA, и даже стажеры могли писать тесты BDD для приложения.

Однако я также использовал его для модульных тестов. Ересь! Я слышу, как некоторые из вас кричат. Однако для этого были ОЧЕНЬ хорошие причины. Система отвечала за составление многих расчетов или определений, основанных на множестве разных данных. Благодаря множеству единичных тестов, которые требуют ввода всех этих данных для целей тестирования, это облегчает управление данными, используемыми для модульных тестов, в формате таблицы, предоставленном specflow. Эффективно высмеивая репозиторий данных в формате таблицы, позволяя энергичным тестировать различные компоненты.

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

Ответ 5

В конце концов мы пытаемся доставить заказчику именно то, что хочет клиент, и поэтому я действительно не вижу необходимости писать модульные тесты в дополнение к SpecFlow. В конце концов, он использует ту же базу кода. Я новичок в BDD/ATDD/TDD, но не будучи "полным" и строго придерживаюсь TDD, мне не нужно писать дополнительные модульные тесты.

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

Ответ 6

Дано:

Единичные тесты - это проверка (небольших) "единиц кода"
Заказчиком большинства "единиц кода" являются другие программисты.
Причиной наличия unit test является пример вызова кода.

Поэтому:

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

Однако:

Иногда таблицы данных необходимы для настройки условий, в которых выполняется unit test.
Большинство фреймворков unit test не подходят для использования таблиц данных.

Поэтому:

Specflow может быть лучшим вариантом для некоторых unit test, но не должен быть выбран по умолчанию.