Как реализовать BDD по очень сложным бизнес-правилам?

Question

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

Я недавно разработал Службу Windows, которая начиналась с малого, но в конечном итоге превратилась в большой шар грязных бизнес-правил. Вот краткий обзор того, что делает служба.

1. Вход в базу данных «Запуск службы ...»

2. Получить данные из БД, которая должна быть размещена на другой веб-службы

3. Если нет никаких данных, чтобы создавать Вход в базу данных «Нет данные для обработки ...» и выездного обслуживания

4. Если данные содержат повторяющиеся значения записывать базы данных«повторяющиеся данные найденными, эта запись будет пропущена.

5. Update был найден статус записи, для которых дублируют данные к чему-то, например 302

6. Если данные нуля, Бревенчатые в базу данных «Запись содержит нулевое значение и не может быть обработана.»

7. Обновление статуса записи надлежащим образом, например, 310

8. Если база данных недоступна или вниз из-за какой-то причине, лаг в файле «База данных вниз ...»

9. Если служба там, где мы должны размещать журнал данных в базу данных «приемник обслуживание вниз.»

10. Вход в базу данных„Exiting службы ...“

Так что моя служба в основном извлекает некоторые данные из базы данных, создает запрос JSON из него и отправить его к другому существу rvice.

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

Из моего понимания BDD не нужно сосредоточиться внутри того, как написано служба, вместо этого он будет тестировать сценарии, служба должна выполнить Например

При выполнении служебных окон с повторяющимися данными

• Он должен регистрироваться в базе данных «Дублированные данные, эта запись будет пропущена.»
• Необходимо обновить статус записи до 302

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

Во-вторых, как служба связывается с БД, а также с веб-службой, как я могу проверить HttpRequest и HttpResponse, которые отправляются и получаются службой?

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

Answer 1

Несколько простых мыслей, чтобы помочь сохранить его в перспективе:

1. Вы говорите, обучение ...
   Имейте это в виду и не зацикливаться на том, что является совершенным, право, или надлежащим образом. Вы учитесь, не стесняйтесь ошибаться и знаете, что улучшаетесь, когда будете идти. Держитесь за это, продолжайте практиковать, вы поправляетесь, и это будет более естественно, чем больше вы делаете, и тем больше вы об этом думаете.
2. BDD-тест поведения.
   Вы используете это, чтобы сказать, что система должна вести себя определенным образом, и это означает, что это должна быть система. Вы по-прежнему можете заглушить пару фиктивных сервисов (например, поддельную службу обработки кредитных карт), но по большей части вы хотите, чтобы это доказывало, что система работает по мере необходимости. Подумайте о них как об интеграционных тестах.
3. Ваши тесты BDD должны вести тесты вашего устройства.
   Запишите BDD-тест на ошибку, а затем пусть это диктует, какие модульные тесты должны быть написаны, чтобы ваша система вела себя так, как вы ожидаете. Это по существу означает, что каждый ваш тест BDD представит набор тестов Unit.
4. Таким образом, пусть BDD-привод TDD , и вы получите правильный баланс тестов. Отправной точкой является ваш первый тест BDD.

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

Досадная вещь при тестировании запросов и ответов Http заключается в том, что вы заканчиваете сравнение строк, но это выполнимо. Тесты BDD должны просто заботиться о том, чтобы система реагировала так, как вы ожидаете.

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

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