테스트를 작성, 구성 및 구성하는 방법에는 여러 가지가 있습니다.
이러한 패턴 중 하나는 Given-When-Then입니다.

이 용어는 행동 주도 개발 프로세스의 일부로 개발되었습니다( 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.

Java의 테스트 시나리오

소프트웨어 개발 테스트의 세계에서 이 패턴을 사용할 때 팀이 만든 규칙에 동의하는 것이 중요합니다. 이것은 모든 서면 테스트의 일관성을 보장합니다.

일관성은 특정 사용 사례의 작동 방식을 빠르게 이해하고 학습하는 데 큰 이점이 됩니다.
새로운 개발자가 팀에 합류했다고 상상해보십시오. 테스트를 읽는 것만으로도 그는 어떤 것이 어떻게 작동해야 하는지, 심지어 응용 프로그램에서 작동할 수 있는지에 대한 지식을 얻을 수 있습니다.

일반적으로 이러한 규칙은 팀에서 정의하고 동의해야 합니다. Given-When-Then 패턴의 경우 저는 항상 두 가지 요소에 주의를 기울입니다.

테스트 방법 구성하기

테스트 메소드 이름 지정

테스트 방법의 구조

패턴이 말하듯이 주어진 시나리오(또는 사용 사례)에는 항상 세 부분이 있습니다.
테스트 방법은 정확히 이 세 부분으로 구성될 수 있습니다.

첫 번째는 항상 주어진 부분입니다. 시나리오의 초기 값입니다. 이것은 기본적으로 모든 테스트에 대한 설정입니다.

두 번째는 때 부분입니다. 이것은 테스트할 원하는 메서드의 실행이거나 이전에 지정된 대로 발생하는 이벤트입니다.

세 번째로 그 다음 부분. 이벤트가 발생한 후 값의 확인 또는 주장.

책을 구매하는 기능을 테스트하는 테스트에 이 구조를 적용하면 다음과 같이 보일 수 있습니다.

// given
String shouldBuyer = "[email protected]";
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() {
    ...
}

긴 메서드 이름에 대한 주제를 Google에서 검색해 본 적이 있다면 이 주제에 대해 많은 토론이 있다는 것을 알고 있을 것이며 여기에는 그럴만한 이유가 있습니다.

긴 이름은 메서드에 대한 복잡한 구현을 의미할 수 있습니다.
그리고 개발자가 메서드를 이해하는 데 필요한 정보를 잃지 않고 메서드 이름을 줄일 수 없다고 생각한다면 너무 복잡한 것이 사실일 수 있습니다.

반면에 테스트의 경우 이 인수가 적용되지 않습니다. 우리는 구현을 테스트할 뿐 일부 논리를 구현하지 않습니다. 테스트는 테스트 러너 이외의 다른 곳에서도 호출되지 않으므로 긴 메서드 호출로 코드를 복잡하게 만들지 않습니다.

결론

Given-When-Then 패턴은 주어진 테스트 시나리오를 정의하는 데 사용할 수 있습니다.
소프트웨어 개발의 세계에서 구현하는 것은 팀이 동의한 규칙에 따라 수행할 수 있습니다.
다른 패턴도 마찬가지입니다.

따라서 팀에서 사용하기로 선택한 패턴, 라이브러리 또는 프레임워크가 무엇이든,
가장 중요한 것은 팀이 사용하는 것에 동의하여 소프트웨어를 개발하고 테스트하는 일관된 방법을 보장할 수 있다는 것입니다.
이것은 장기적으로 팀이 기능을 추가로 개발하고 애플리케이션을 유지 관리하며 세계에서 무슨 일이 일어나고 있는지 계속 이해하는 데 도움이 될 것입니다.

더 읽기

https://martinfowler.com/bliki/GivenWhenThen.html

https://dannorth.net/introducing-bdd/

https://en.wikipedia.org/wiki/Behavior-driven_development