Представляем Cucumber для Java + СТАНДАРТНЫЕ Значения

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

Cucumber JVM — это инфраструктура тестирования, которая расширяет JUnit , чтобы обеспечить более простой способ начать разработку на основе поведения (BDD). Язык огурцов (язык, который понимает Cucumber), позволяет программисту или инженеру по качеству легче описать словами сценарии ожидаемого поведения в программном приложении.

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

Развитие приложений и изменение требований

Я считаю, что спецификация требований к программному обеспечению — это скорее форма искусства. Было бы здорово, если бы мы спросили экспертов по бизнес-тематике (МСП), что они хотят, чтобы приложение делало, и попросили их абстрактно предоставить все необходимые детали. К сожалению, каждый проект, над которым я работал в течение последних 30 с лишним лет и который пытался собрать требования заранее, сталкивался с неизбежной ситуацией изменения или неправильного понимания требований на полпути в процессе разработки, что заставляет заподозрить все требования, которые еще не реализованы.

Как сторонник гибкой методологии, я считаю, что лучшие приложения развиваются. Требования должны формироваться со временем. Эта концепция сводит с ума руководителей проектов и даже заинтересованных лиц. «Как я могу планировать три года, если я точно не знаю, какие требования предъявляются в каждом выпуске?»

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

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

Зачем использовать огурец?

Cucumber и JUnit — это инструменты, которые позволяют мне автоматизировать важные возможности и сценарии использования моего приложения. Будучи проворным разработчиком, я должен рассчитывать на рефакторинг кода и дизайна в ответ на изменения требований; модульные и интеграционные тесты, которые я пишу, дают мне уверенность в том, что сценарии, протестированные в прошлом, все еще работают. Этот факт, почему мы юнит тест, но все же остается вопрос, почему огурец?

Для меня Cucumber появился на сцене, когда проект, которым я руководил, решил перейти на JEE6, CDI и Interceptors. Все эти концепции повторно используют сервисы, а также используют Аспектно-ориентированное программирование для вставки поведения бизнес-правил в сервисные методы. То есть мы решили использовать перехватчик Java, чтобы обеспечить соблюдение бизнес-правил при каждом вызове метода службы до того, как вызов был запущен.

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

В то время существовал только один набор инструментов, который бы справлялся с этой средой: Cucumber и Arquillian. Arquillian — это тестовая среда от Redhat, которая позволяет «сжать» развертываемый ресурс, который можно использовать в тестовом контейнере, чтобы ваш интеграционный тест действительно выполнялся в контейнере. Как настроить это и заставить его работать, является более сложной темой, чем я расскажу здесь, но, начиная с тестовой среды Arquillian Cucumber, нельзя было опускать пальцы ног в воду; это было больше похоже на рывок медузы.

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

Пример был бы великолепен прямо сейчас.

Пока что это, вероятно, звучит как рекламный ход, но позвольте мне продемонстрировать, как выглядит тест на огурец. Давайте возьмем для примера форму 1040EZ.

Если бы мы писали заявление для этого, нам может понадобиться следующий сценарий:

Итак, давайте рассмотрим этот сценарий. Словосочетание «Характеристика и сценарий» — это просто текст, используемый для описания того, что мы тестируем в целом, и о чем конкретный сценарий. Заданный синтаксис «когда» и «затем» — это общий жаргон-тест, используемый для различения различных частей сценария.

• «Данный» используется для описания настройки теста.
• «Когда» обычно описывает метод Java, который вы тестируете, и параметры, предоставленные ему. Наш пример не имеет параметров.
• «Затем» используется для описания результата выполнения метода. Иногда есть сообщения; в других случаях есть конкретные данные, которые ожидаются; а другие случаи просто проверяют, что ничего не сломалось или не изменилось.

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

• Обязательные значения не указаны
• Противоречивый вклад
• Неверные данные, такие как отрицательные значения или текст, где ожидались числа
• Допустимые сценарии, такие как возврат и оплата

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

Для нашего простого сценария текст Given-When-Then будет храниться в ресурсах нашего Java-кода в виде файла «.feature». Все файлы объектов, как правило, хранятся вместе в наборе папок, имитирующих структуру пакета Java. Фактически, чтобы упростить тестирование, вы создаете класс Java для тестирования этой функции в пакете, который соответствует этой структуре папок.

Класс Java, именуемый в Stec файлом Steps, определяет, какой код Java нужно запускать для каждого шага, который просто представляет собой Given, When или Then. Шаг соответствует шагу функции, используя аннотации @Given, @When и @Then, которые имеют аргументы регулярных выражений, которые используются для сопоставления.

Посмотрите документацию Cucumber для лучших примеров и более подробной информации о том, как все это сочетается.

Подсказка для написания сценариев с огурцом со стандартными значениями

Как отмечено в примере выше, «заданный» шаг устанавливает сценарий. В нашем простом сценарии первое данное, кажется, скрывает некоторые важные данные; в частности, каковы стандартные сообщения для приложения? Более сложные сценарии могут опираться на большие наборы предварительно определенных данных.

Cucumber предоставляет способы перечисления данных в таблицах, чтобы вы могли быть очень явными на каждом «заданном» этапе и показывать зависимые данные настройки. Однако это сделает даже самые простые сценарии настолько многословными, что никто не попытается их прочитать.

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

«…» заменяется ключевыми словами, которые показывают, какие классы объекта должны быть обеспечены стандартными значениями. Это делает каждый сценарий лаконичным и незагроможденным, но если не разработчик смотрит на сценарий, как они узнают, каковы стандартные значения?

Наше решение — предоставить файл StandardObjects.feature. Этот файл, как и все остальные, запускается с «Заданными значениями СТАНДАРТА для…», но в каждом сценарии есть шаг «Тогда», который показывает таблицу ожидаемых значений для этого стандартного объекта.

В приведенном выше примере мы имели:

Используя этот подход к функциям значений STANDARD, мы бы повторно использовали этот Given и поставили Тогда следующим образом:

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

Последние мысли

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

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