TDD VS BDD: REST Service
Я все путаю с TDD против BDD:) Чем отличаются TDD и BDD в каждом из следующих пунктов?
- Разработка: сначала тестовый пример, затем развитие
RestService(HTTP): не делать звонки для отдыха? Если так,
а) мы возвращаем только жестко закодированный JSON, используя фиктивный объект?
б) как обрабатывать сбои вызова REST? У нас тоже должен быть тестовый пример?
Специально для пункта 2 я погуглил так много статей, но не смог найти пример (кодовый) подход к обработке вызовов покоя.
2 ответа
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 абсолютно одинаковы, если они сделаны хорошо. Просто говорить о примерах и сценариях проще, чем о тестах.
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 для связи с внутренним сервером, я бы классифицировал это как интеграционный тест, поскольку вы тестируете интеграцию с компонентом, который вы не делаете. контроль, т.е. фактический бэкэнд-сервер. Интеграционные тесты должны только подтвердить, что сервер возвращает данные JSON в формате, ожидаемом вашим приложением, или что ошибки возвращаются при необходимости.