tl; dr вы можете использовать метки, чтобы уточнить стиль тестирования «когда да».
Что дается-когда-то?
данный-когда-то — это обычно используемый стиль определения поведения системы, при котором ваши тесты делятся на три раздела.
- Дан раздел, в котором изложены предварительные условия для теста, т. Е. В каком состоянии вы предполагаете находиться в мире перед началом.
- Предложение When выполняет тестируемое действие.
- Оператор Then проверяет, выполняется ли условие post. Обычно это делается в форме утверждения значений или проверки взаимодействия с макетами.
Это не всегда тот случай, когда вам нужно иметь три раздела в коде каждого теста. Например, данный раздел может быть покрыт общим методом setUp
. Я думаю, что это хорошая идея, чтобы следовать шаблону и разделить различные разделы, потому что это позволяет вам четко видеть дерево с деревьев.
Использование ярлыков с Junit
В некоторых проектах я экспериментировал с тем, чтобы пойти немного дальше, чем просто разделить данные / когда / затем и использовать метки Java, чтобы выложить различные разделы теста, чтобы прояснить ситуацию * . Следующий фрагмент кода показывает, как вы можете реализовать это с помощью Junit.
01
02
03
04
05
06
07
08
09
10
11
12
13
|
Cafe cafe = new Cafe(); @Test public void cafeShouldNeverServeCoffeeItDoesntHave() { Given: cafe.setCoffeesRemaining( 1 ); When: cafe.serveCoffee(); Then: assertFalse(cafe.canServeCoffee()); } |
Это очень простой пример для демонстрации макета. Наш тест проверяет, что Cafe
никогда не подает кофе, которого у него нет. Существует четкое разграничение трех разделов кода по меткам. Немного необычно видеть, как используются такие метки — они наиболее часто используются в Java как способ вырваться из вложенных циклов за один раз. Конечно, нет никакой реальной причины не использовать их таким образом, это просто стилистический вопрос, и нет никакой семантической разницы между кодом с метками и без них.
Использование ярлыков с лямбда-поведением
Хотя я уверен, что большинство разработчиков Java используют Junit, я недавно выпустил новую библиотеку под названием Lambda Behave . Это разработано, чтобы быть современной структурой тестирования и поведенческой спецификации для Java 8, которая облегчает написание беглых и удобочитаемых тестов. В лямбда-поведении вы пишете тесты, перечисляя описательную строку вместо ограничительного имени метода и описывая тело теста в лямбда-выражении. Я обнаружил, что тесты, написанные в этом стиле, намного легче читать.
Вы можете использовать тот же заданный / когда / затем стиль метки в лямбда-поведении, как показано в следующем примере кода:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
|
describe( "a cafe" , it -> { Cafe cafe = new Cafe(); 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. Там не так много кода, потому что это просто очень простые примеры, но может быть полезно показать, что никакой магии не происходит!
Я показал, как вы можете использовать метки, чтобы прояснить назначение блоков кода в этом посте, и, надеюсь, это метод, который люди находят полезным и полезным. Независимо от того, используете ли вы ярлыки для реализации данных «когда тогда» или нет, я надеюсь, что люди пишут свои тесты в соответствии с неким соглашением. Это действительно делает происходящее намного понятнее. Я уверен, что некоторые люди имеют мнения по этому вопросу, поэтому дайте мне знать, вы думаете, это хорошая идея или нет?
* Я / думаю /, что я получил идею от Хосе Лларены после разговора с ним на мероприятии LJC, так что спасибо Хосе!
Ссылка: | Предоставлено «Когда тогда на Яве» от нашего партнера по JCG Ричарда Уорбертона в блоге Insightful Logic . |