Вне BDD (с Specflow)

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

1. Декларативные или императивные сценарии?

Большинство сценариев, которые я видел, когда-то были написаны с точки зрения UI (императив).

Scenario: Login
     Given I am on the Login-page
     When I enter 'AUser' in the textbox 'UserName'
       And I enter 'APassword' in the textbox 'Password'
       And I click the 'Login' button
     Then I should see the following text 'You are logged in'

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

Scenario: Login (declarative)
     Given I am not logged in
     When I log in using valid credentials
     Then I should be logged in

Если вы предпочитаете декларативный стиль, как вы описываете такие вещи, как "Домашняя страница" или "Страница продуктов"?

Советы по написанию хороших спецификаций

2. Управлять пользовательским интерфейсом или нет?

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

Как вы реализуете сценарии в реальных проектах - реализуете пользовательский интерфейс или через контрольные контроллеры/презентаторы?

Лучший способ применения BDD

3. Реальная база данных или нет?

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

Ожидание опытных ответов!

UPDATE: добавлены полезные ссылки по вопросам.

Ответ 1

Декларация - это правильный путь, ИМО. Если вы говорите о имени файла .aspx, вы делаете это неправильно. Цель этой истории - облегчить общение между разработчиками и не-develoeprs. Не-разработчикам не заботятся о products.aspx, они заботятся о листинге продукта. Ваша система делает то, что не-разработчики находят значение. Это то, что вы пытаетесь захватить.
Хорошо, рассказы рассказывают о функциях высокого уровня, которые вам нужно реализовать. Это то, что должна делать ваша система. Единственный способ узнать, выполнили ли вы это, - это фактически использовать пользовательский интерфейс. Рассказы BDD SpecFlow для меня не заменяют модульные тесты, скорее это вы интеграционные тесты. Если вы нарушите это, вы нарушите значение, получаемое от вашего программного обеспечения. Единичные тесты - это детали реализации, которые ваши пользователи не заботятся, и они проверяют каждую часть отдельно. Это не может сказать вам, если A и B на самом деле работают вместе все время (теоретически это должно на практике интересно [читать: неожиданные] вещи, когда у вас фактически есть две части, играющие друг с другом). Автоматизированные сквозные тесты могут также помочь в вашем QA. Если функциональная область ломается, вы знаете об этом, и они могут тратить свое время в других областях приложения, пока вы определяете, что нарушило интеграционные тесты.
Это сложный вопрос. Мы сделали гибридный подход. Мы используем базу данных (интегрируем тесты после тестирования системы, функционирующей как одна вещь, а не отдельные компоненты), но вместо того, чтобы перезагружать конфигурации все время, мы используем Deleporter для замены наших репозиториев с помощью Moqs, когда нам нужно. Кажется, что все работает нормально, но в любом случае есть плюсы и минусы. Я думаю, что мы по-прежнему в основном это понимаем.

Ответ 2

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

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

Он также упоминает абсолютную "декларативную" или "императивную" модель, являющуюся мифом. Он говорит о когнитивной модели под названием "chunking", говоря, что на любом уровне вашей абстракции вы можете "раскалывать" или "обрывать". Это означает, что вы можете получить более явные (как?) Или более мета (что или почему?). Вы отказываетесь от императивной модели, спрашивая: "Что мы делаем?" Вы говорите: "Как мы это сделаем?" Поэтому я предполагаю, что я не стал бы слишком зависеть от декларативного и императивного - он не приведет вас никуда, пока проблема не исчезнет.

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

Кстати, он также использует сценарий входа в пользовательский интерфейс, поэтому у вас есть конкретные рекомендации:)

Перед редактированием: (некоторые из них по-прежнему применяются. Вопросы "DB или no DB" и "UI or no UI" не связаны)

1 - Декларативные или императивные сценарии?

Декларативный, если вы можете, хотя императив имеет некоторое значение (в некоторых точках жизненного цикла проекта).

Imperative - это более простой способ подумать для тестеров и бизнес-аналитиков, которые не так знакомы с теорией и дизайном информации. Об этом также легче думать ранее в проекте, прежде чем вы пригвоздили свой проблемный домен и рабочие процессы. Это может быть полезно для поискового мышления.

Декларативный менее подвержен изменениям с течением времени. Поскольку GUI является частью приложения, которое больше всего подвержено оттоку по прихоти, это чрезвычайно ценно. Легче подумать, как только вы пригвоздили свой проблемный домен и рабочие процессы и больше ориентированы на реляционные концепции. Это более стабильная и более общеприменимая модель.

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

как вы описываете такие вещи, как "Домашняя страница" или "Страница продуктов"?

Я не уверен, что буду на базовом уровне функций и требований. Вы можете сделать вспомогательные функции и подзадачи, которые описывают детали реализации, такие как конкретные рабочие процессы пользовательского интерфейса. Если вы описываете часть пользовательского интерфейса, тогда вам следует определить функцию/требование пользовательского интерфейса.

2 - Управлять пользовательским интерфейсом или нет?

И.

Я думаю, что его чрезвычайно медленный и хрупкий

Да, это так. Выполняйте каждый сценарий/требования высокого уровня с помощью пользовательского интерфейса и полной интеграции с БД, но не выполняйте каждый путь кода с помощью автоматизации конечного интерфейса, и, конечно же, не делайте ошибок. Если вы это сделаете, вы потратите больше времени на их работу и намного меньше времени на тестирование своего приложения.

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

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

3 - Реальная база данных или нет?

И.

Всеобъемлющие интеграционные тесты высокого уровня должны выполняться с полной системой. Это включает в себя реальную БД, выполнение тестов с каждой системой на другом сервере и т.д.

Чем ниже уровень, тем больше я защищаю насмешливые объекты.

Модульные тесты должны тестировать только отдельные классы
Тесты интеграции на уровне среднего уровня должны избегать дорогостоящих, хрупких и влиятельных зависимостей, таких как файловая система, базы данных, сеть и т.д. Попробуйте протестировать реализацию этих хрупких и влиятельных зависимостей с помощью модульных тестов и сквозных только тесты.

Ответ 3

Вместо того, чтобы упоминать страницу по имени, опишите, что она представляет, например

Scenario: Customers logs in successfully

  When I log in
  Then I should see an overview of ACME top selling products

Вы можете протестировать непосредственно против базовых API или моделей, но чем больше вы это сделаете, тем больше вы рискуете не улавливать проблему интеграции. Один из подходов состоит в том, чтобы сбалансировать вещи с небольшим количеством тестов с полным стеком и большим числом, которое проверяет только два слоя.