Учитывая, Когда Тогда Шаблон

Существует множество различных способов написания, организации и структурирования ваших тестов. Одним из таких шаблонов является Дано-Когда-То .

Этот термин был разработан как часть процесса разработки, основанного на поведении ( https://dannorth.net/introducing-bdd/ ). В целом он описывает шаблон того, как писать, и описывает желаемый сценарий.

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

Определение сценария с использованием этого шаблона может выглядеть следующим образом.

Scenario: A user wants to buy a book from a well known e-commerce platform.

Given the user owns no books from this platform.
When the user orders and receives the ordered book from the platform.
Then the user should have one book in his possession.

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

Согласованность – это большое преимущество, помогающее быстро понять, а также узнать, как должны работать определенные варианты использования. Представьте, что к команде присоединяется новый разработчик. Просто прочитав тесты, он получит знания о том, как что-то должно и даже может работать в приложении.

В целом, эти соглашения должны быть определены и согласованы командой. В случае Заданного-Когда-шаблона Я всегда обращаю внимание на два фактора.

Структурирование метода испытаний
Присвоение имени методу тестирования

Структура метода испытаний

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

Первой всегда является данная часть. Начальные значения для сценария. Это в основном настройка для любого теста.

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

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

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

// given
String shouldBuyer = "hanswurst@test.com";
Long anyBookId = 1L;

// when
UserBook actual = sut.buyBook(shouldBuyer, anyBookId);

// then
assertThat("the actual owner of the book, should be the buyer", 
    actual.getBuyer(), equalTo(shouldBuyer));

Название метода испытания

Обычно я предпочитаю короткие самодокументируемые имена для методов. Однако для тестов я исключил “короткое замыкание” из этого предпочтения.

Тест всегда должен указывать, что он пытается протестировать. Конечно, вы могли бы сделать это, задокументировав его с помощью некоторого Javadoc, или вы могли бы просто назвать тест так, как вы обычно его документируете.

Применяя шаблон Given-When-Then к этому определению, название нашего теста на покупку книг будет выглядеть примерно так.

@Test
public void givenValidUserNameAndBookId_whenBuyBook_thenUserShouldOwnNewBook() {
    ...
}

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

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

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

Шаблон Given-When-Then может использоваться для определения любого заданного тестового сценария. Внедрить его в мир разработки программного обеспечения можно, следуя соглашениям, согласованным командой. Это верно и для других моделей.

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

Оригинал: “https://dev.to/smotastic/givenwhenthen-pattern-5bno”