SpecFlow и альтернативный подход к тестированию

[muradovm]

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

[VladVR]

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

[Quilin]

SpecFlow, будучи транслированным на .NET Cucumber, это не альтернатива NUnit (его можно настроить генерировать код NUnit-тестов, например), а реализация BDD — Behaviour Driven Development.
Тесты, написанные в этом стиле, во-первых, оборачиваются в человеко-читаемый язык (все эти Given-When-Then, Outline и прочая значительно облегчают чтение тестов для тех, кто не знаком с языком или не имеет возможности вникать в детали реализации). Скажем, если у вас под строчкой Given User 'U1' has Product 'P1' in product card скрывается пяток вызовов API (всякое же бывает) — плюс очевиден.
Во-вторых, сам подход подразумевает деление тесткейса на шаги, которые в дальнейшем могут быть повторно вызваны. В «классическом» подходе к юнит-тестам это нередко считается bad practice — приватные методы в тестах.

Что не нравится в SpecFlow, но что, кажется, будет решено в новой версии — это непрозрачность в порядке подключения hooks. Ну, скажем, если у вас есть два класса, в которых имеются методы с атрибутами типа Before/After-Feature/Scenario, им нельзя указать приоритет выполнения. И это грустно. Опять же, когда в том же NUnit можно использовать наследование в классах тестов, здесь это полностью исключено. И это нередко затрудняет процесс.

[muradovm]

BDD не отменяет возможность использования NUnit. Просто эти тесты будут интеграционными.
Оборачивание 5ти вызовов API в человекочитаемый вид имеет не только плюсы, но и минусы. Например, любые изменения в API нужно будет руками править в тестах. Как часто человек, не знающий языка программирования заглядывает в тесты проекта? Стоит ли ради этого отказываться от нормальной поддержи тестов?

[Quilin]

BDD не отменяет возможность использования NUnit.

Именно это я и сказал.

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

Ну, во-первых, не любые, а во-вторых, при тестировании API вам так и так придется править тесты при существенном изменении тестируемого объекта.

BDD не альтернатива юнит-тестированию, никоим образом. Я лично считаю, что в проекте хорошо держать и те, и другие. Даже некоторые интеграционные тесты (например, хитрожопые запросы к базе данных) не обязательно писать в BDD-стиле. Просто «нормальная» поддержка тестов показывает стабильность работы приложения для разработчиков, а BDD — для всех. Это однозначно хорошо.

Как часто человек, не знающий языка программирования заглядывает в тесты проекта?

Зависит от проекта. У меня, например, owner заглядывает регулярно =).

[VladVR]

-> Как часто человек, не знающий языка программирования заглядывает в тесты проекта?
именно поэтому и не заглядывает, разве нет?

[muradovm]

Я про то же. Зачем нужен этот человекочитаемый тест программисту.
Хотя выше писали обратное — такие тесты смотрят.

[LSD]

У нас на кукумбере аналитики пишут юзкейсы. А потом по этим тюзкейсам мы гоняем интеграционные аксептанс тесты.

[forcewake]

В качестве реального use-case могу предложить такой вариант развития событий:

• Новый для вас проект с большим слоем-бизнес логики
• Поступает feature-request от business owner'a
• Для создания общего словаря и более углубленного понимания того, что вам нужно сделать все требования оформляются в качестве таких вот Given-When-Then тестов

Пример такого теста

@ignore
Feature: UserAccess	

@web
Scenario: Try to get access to Some_Part_Of_The_Application
  Given I open 'Application_Name' application as 'User'.
  When I navigate to 'Some_Part_Of_The_Application'.
  Then Menu navigation causes exception.