Статьи

Учитывая, когда тогда в Java

Март 3, 2018

tl; dr вы можете использовать метки, чтобы уточнить стиль тестирования «когда да».

Что дается-когда-то?

Given-when-then — это широко используемый стиль определения поведения системы, при котором ваши тесты делятся на три раздела.

  • Дан раздел, в котором изложены предварительные условия для теста, т. Е. В каком состоянии вы предполагаете находиться в мире перед началом.
  • Предложение When выполняет тестируемое действие.
  • Оператор Then проверяет, выполняется ли условие post. Обычно это делается в форме утверждения значений или проверки взаимодействия с макетами.

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

Использование ярлыков с Junit

В некоторых проектах я экспериментировал с тем, чтобы пойти немного дальше, чем просто разделить данные / когда / затем и использовать метки Java, чтобы выложить различные разделы теста, чтобы прояснить ситуацию по-настоящему [0] . Следующий фрагмент кода показывает, как вы можете реализовать это с помощью Junit.

Cafe cafe =newCafe();@Testpublicvoid cafeShouldNeverServeCoffeeItDoesntHave(){Given:
        cafe.setCoffeesRemaining(1);When:
        cafe.serveCoffee();Then:
        assertFalse(cafe.canServeCoffee());}

Это очень простой пример для демонстрации макета. Наш тест проверяет, что Cafeникогда не подают кофе, которого у него нет. Существует четкое разграничение трех разделов кода по меткам. Немного необычно видеть, как используются такие метки — они наиболее часто используются в Java как способ вырваться из вложенных циклов за один раз. Конечно, нет никакой реальной причины не использовать их таким образом, это просто стилистический вопрос, и нет никакой семантической разницы между кодом с метками и без них.

Использование ярлыков с лямбда-поведением

Хотя я уверен, что большинство разработчиков Java используют Junit, я недавно выпустил новую библиотеку под названием Lambda Behave . Это разработано, чтобы быть современной структурой тестирования и поведенческой спецификации для Java 8, которая облегчает написание беглых и удобочитаемых тестов. В лямбда-поведении вы пишете тесты, перечисляя описательную строку вместо ограничительного имени метода и описывая тело теста в лямбда-выражении. Я обнаружил, что тесты, написанные в этом стиле, намного легче читать.

Вы можете использовать тот же заданный / когда / затем стиль метки в лямбда-поведении, как показано в следующем примере кода:

    describe("a cafe", it ->{Cafe cafe =newCafe();

        it.should("never serve coffee it doesn't have", expect ->{Given:
            cafe.setCoffeesRemaining(1);When:
            cafe.serveCoffee();Then:
            expect.that(cafe.canServeCoffee()).is(false);});});

Ограничения и альтернативы

Самым большим неудобством использования меток таким образом является то, что по неизвестной мне причине вы не можете написать метку до объявления объявления переменной в Java. Это означает, что если вы хотите начать Given:предложение, используя новую переменную, вам нужно поднять объявление переменной в верхнюю часть блока или в поле. Я не считаю, что это большая проблема, и на самом деле подъем может привести в порядок вещи еще дальше.

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

Некоторые люди используют альтернативные модели «задано / когда / потом», которые похожи, но имеют больше фаз, таких как четырехфазный подход к тестированию, или даже разные имена, такие как Arrange, Act, Assert . С этими стилями также можно использовать соглашение на основе меток или комментариев.

Выводы

Я поместил пример кода на github, если кто-то хочет посмотреть или поиграть в своей IDE. Там не так много кода, потому что это просто очень простые примеры, но может быть полезно показать, что никакой магии не происходит!

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

Благодарю Рауля Габриэля Урму , Криса Уэста и Джеймса Росса за комментарии к сообщению в блоге.

[0] Я / думаю / что у меня появилась идея от Хосе Лларены после разговора с ним на мероприятии LJC, так что спасибо Хосе!

33
Share: