TDD VS BDD: служба REST

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

BDD - это больше, чем просто написание тестов с англоязычным синтаксисом, например Киви. BDD (также известный как ATDD - Acceptance Test Driven Development) начинается с разработчиков, QA и дизайнеров (например, бизнес-дизайнеров и дизайнеров взаимодействия), работающих вместе для выработки общего понимания предлагаемого решения. Обычно для иллюстрации поведения используются примеры, также известные как «Спецификация на примере».

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

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

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

Фазы стандартного цикла TDD - красный, зеленый, рефакторинг. Во время зеленой фазы ваша цель состоит в том, чтобы пройти тест как можно быстрее, всеми правдами и неправдами - допустимо писать уродливый, неорганизованный код. После прохождения теста вы реорганизуете код, чтобы сделать его более читабельным / изменяемым.

Точно так же с циклом BDD / ATDD у вас есть красный, зеленый, рефакторинг. Во время зеленой фазы BDD просто пройдите приемочные испытания. Весь код, который вы пишете, может существовать внутри самого теста. На этапе рефакторинга BDD вы извлекаете тестовый код в производственный код. Вы можете использовать TDD для управления извлечением.

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

Что касается тестирования вызовов REST, давайте вернемся к предпосылке абстракции - различению того, что мы делаем, от того, как мы это делаем.

Вызов службы REST - это конкретное действие. Политика, которой он удовлетворяет, может заключаться в предоставлении списка объектов модели.

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

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

Когда вы используете TDD для реализации класса, который обрабатывает связь с сервером, у вас могут быть тесты, которые извлекают JSON из удаленного источника данных (т. Е. С сервера) и гарантируют, что JSON правильно анализируется на объекты модели User. У вас также могут быть тесты, чтобы охватить источник данных, отвечающий с ошибкой, и т. Д.

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

BDD на самом деле является производным от TDD, поэтому неудивительно, что есть небольшая путаница! BDD в точности похож на TDD (или ATDD, если вы делаете это для всей системы), но без слова «Test». Оказывается, это может быть довольно мощно.

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

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

Я: Что ему делать?
Вы: Он должен позволить мне прочитать запись.
Я: Отлично! Можете ли вы привести мне пример записи?
Вы: У меня есть одна ...
Я: Есть ли контекст, в котором кому-то не следует? не можете прочитать запись?
Вы: Конечно, если у них нет разрешений.

...

Я: Хорошо, я закончил читать, давайте обновим. Можете ли вы привести мне пример типичного обновления?
Вы: Вот, пожалуйста.
Я: Замечательно, и вы хотите, чтобы оно отвечало просто успешно или потерпеть неудачу. Есть ли сценарий, при котором он должен потерпеть неудачу?
Вы: Конечно. Запись показывает, когда она была обновлена ​​в последний раз. Если кто-то еще уже обновил его тем временем, ваш должен потерпеть неудачу, когда вы его отправите.

Итак, вы видите, что вы можете использовать BDD для изучения всех видов сценариев, в том числе сценариев, связанных со службой REST. Уловка состоит в том, чтобы спросить: «Вы можете привести мне пример?» Тогда вы получите конкретный пример, который при желании можете автоматизировать. Беседы помогают нам искать другие примеры и сценарии, которые мы могли пропустить.

Не используйте инструменты BDD для автоматизации для технической аудитории! Инструменты BDD, такие как Cucumber, JBehave и т. Д., Работают с настоящим английским языком, который намного сложнее реорганизовать, чем код. Используйте JUnit, NUnit и т. Д., Если вы просто делаете что-то вроде службы REST. Вы можете написать «Дано, Когда, Тогда» в комментариях или сделать небольшой DSL.

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

Я: Итак, эта ошибка вызова ... вы можете привести мне пример?
Вы: Конечно, если вы получите доступ к удаленной записи, она потерпит неудачу .
Я: Приведите типичный пример записи, которая может быть удалена?
Вы: Хорошая запись, которую мы использовали раньше.
Я: Хорошо, есть ли ситуация, при которой нам не следует удалять запись?
Вы: Да, если она уже была опубликована ...

И Т. Д.

Вы можете видеть, что я на самом деле не использую слово «тест». Тесты - хороший побочный продукт в BDD. Он больше используется для исследования и уточнения требований. Разговоры в BDD - самая важная его часть.

Причина, по которой сложно найти примеры использования BDD для REST, заключается, во-первых, потому, что REST намеренно прост и не часто имеет много поведения, а во-вторых, потому, что сценарии BDD обычно не формулируются с точки зрения их реализации, вместо этого сосредотачиваясь на ценность того, что предоставляет услуга или система («прочитать запись»).

TDD и ATDD - это одно и то же, если они сделаны хорошо. Просто поговорить о примерах и сценариях проще, чем о тестах.