Comments 9
Вот уже как лет пять слежу за SpecFlow, даже пробовал не раз, но никак не пойму, как его использовать в реальном проекте. Как минимум высокая стоимость написания и поддержки теста по сравнению с NUnit каким-нибудь. Можете привести пример, где именно без SpecFlow не обойтись?
0
А без него можно обойтись. У него высокий порог вхождения, немалый оверхэд. А плюсы становятся заметны не сразу.
Переиспользование становятся заметным лишь когда написано некоторое критическое количество тестов. А читаемость становится наиболее заметна уже при поддержке, а не при написании. Тесты написаны «человеческим» языком, и для того, чтобы разобраться что именно проверяет тот или иной тест нужно существенно меньше времени. Кроме того полностью исчезает какая либо необходимость оставлять комментарии в коде теста.
А использовать его можно точно также, я вроде как пример даже привел. Правда этот пример живет не в этом проекте, а в соседнем на гитхабе.
Переиспользование становятся заметным лишь когда написано некоторое критическое количество тестов. А читаемость становится наиболее заметна уже при поддержке, а не при написании. Тесты написаны «человеческим» языком, и для того, чтобы разобраться что именно проверяет тот или иной тест нужно существенно меньше времени. Кроме того полностью исчезает какая либо необходимость оставлять комментарии в коде теста.
А использовать его можно точно также, я вроде как пример даже привел. Правда этот пример живет не в этом проекте, а в соседнем на гитхабе.
0
SpecFlow, будучи транслированным на .NET Cucumber, это не альтернатива NUnit (его можно настроить генерировать код NUnit-тестов, например), а реализация BDD — Behaviour Driven Development.
Тесты, написанные в этом стиле, во-первых, оборачиваются в человеко-читаемый язык (все эти Given-When-Then, Outline и прочая значительно облегчают чтение тестов для тех, кто не знаком с языком или не имеет возможности вникать в детали реализации). Скажем, если у вас под строчкой
Во-вторых, сам подход подразумевает деление тесткейса на шаги, которые в дальнейшем могут быть повторно вызваны. В «классическом» подходе к юнит-тестам это нередко считается bad practice — приватные методы в тестах.
Что не нравится в SpecFlow, но что, кажется, будет решено в новой версии — это непрозрачность в порядке подключения hooks. Ну, скажем, если у вас есть два класса, в которых имеются методы с атрибутами типа Before/After-Feature/Scenario, им нельзя указать приоритет выполнения. И это грустно. Опять же, когда в том же NUnit можно использовать наследование в классах тестов, здесь это полностью исключено. И это нередко затрудняет процесс.
Тесты, написанные в этом стиле, во-первых, оборачиваются в человеко-читаемый язык (все эти Given-When-Then, Outline и прочая значительно облегчают чтение тестов для тех, кто не знаком с языком или не имеет возможности вникать в детали реализации). Скажем, если у вас под строчкой
Given User 'U1' has Product 'P1' in product card
скрывается пяток вызовов API (всякое же бывает) — плюс очевиден.Во-вторых, сам подход подразумевает деление тесткейса на шаги, которые в дальнейшем могут быть повторно вызваны. В «классическом» подходе к юнит-тестам это нередко считается bad practice — приватные методы в тестах.
Что не нравится в SpecFlow, но что, кажется, будет решено в новой версии — это непрозрачность в порядке подключения hooks. Ну, скажем, если у вас есть два класса, в которых имеются методы с атрибутами типа Before/After-Feature/Scenario, им нельзя указать приоритет выполнения. И это грустно. Опять же, когда в том же NUnit можно использовать наследование в классах тестов, здесь это полностью исключено. И это нередко затрудняет процесс.
0
BDD не отменяет возможность использования NUnit. Просто эти тесты будут интеграционными.
Оборачивание 5ти вызовов API в человекочитаемый вид имеет не только плюсы, но и минусы. Например, любые изменения в API нужно будет руками править в тестах. Как часто человек, не знающий языка программирования заглядывает в тесты проекта? Стоит ли ради этого отказываться от нормальной поддержи тестов?
Оборачивание 5ти вызовов API в человекочитаемый вид имеет не только плюсы, но и минусы. Например, любые изменения в API нужно будет руками править в тестах. Как часто человек, не знающий языка программирования заглядывает в тесты проекта? Стоит ли ради этого отказываться от нормальной поддержи тестов?
0
BDD не отменяет возможность использования NUnit.
Именно это я и сказал.
Например, любые изменения в API нужно будет руками править в тестах
Ну, во-первых, не любые, а во-вторых, при тестировании API вам так и так придется править тесты при существенном изменении тестируемого объекта.
BDD не альтернатива юнит-тестированию, никоим образом. Я лично считаю, что в проекте хорошо держать и те, и другие. Даже некоторые интеграционные тесты (например, хитрожопые запросы к базе данных) не обязательно писать в BDD-стиле. Просто «нормальная» поддержка тестов показывает стабильность работы приложения для разработчиков, а BDD — для всех. Это однозначно хорошо.
Как часто человек, не знающий языка программирования заглядывает в тесты проекта?
Зависит от проекта. У меня, например, owner заглядывает регулярно =).
0
-> Как часто человек, не знающий языка программирования заглядывает в тесты проекта?
именно поэтому и не заглядывает, разве нет?
именно поэтому и не заглядывает, разве нет?
0
У нас на кукумбере аналитики пишут юзкейсы. А потом по этим тюзкейсам мы гоняем интеграционные аксептанс тесты.
0
В качестве реального 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.
0
Sign up to leave a comment.
SpecFlow и альтернативный подход к тестированию