이 글은 Martin Fowler의 GivenWhenThen 내용을 번역한 글 입니다.
Given-When-Then은 SpecificationByExample을 사용한 시스템 행동방식을 구체화한 테스트를 대표하는 스타일이다. (이 방법을 옹호하는 사람이 그렇게 말하는 것일 수도 있다) 이 방법은 Behavior-Driven Development (BDD) 중 하나로 Daniel Terhorst-North와 Chris Matts에 의해 개발되었다. 이는 Cucumber와 같은 많은 테스팅 프레임워크를 위한 구조적인 접근방식으로 나타났다. 또한 Four-Phase Test 패턴의 재구조화 시킨 것이라고 볼 수도 있다.
Given-When-Then의 중요한 개념은 테스트를 세 부분으로 나눌 수 있는 것이다.
- given 파트는 테스트에서 구체화하고자 하는 행동을 시작하기 전에 테스트 상태를 설명하는 부분이다.
- when 파트는 구체화하고자 하는 그 행동이 된다.
- then 파트는 어떤 특정한 행동 때문에 발생할거라고 예상되는 변화에 대해 설명하는 부분이다.
구체화를 위해 계속 예제를 사용해왔기 때문에, 이 개념을 예제와 함께 보여주는 것이 더 이해를 잘 될 것이다.
기능 : 사용자 주식 트레이드
시나리오 : 트레이드가 마감되기 전에 사용자가 판매를 요청
"Given" 나는 MSFT 주식을 100가지고 있다.
그리고 나는 APPL 주식을 150가지고 있다.
그리고 시간은 트레이드가 종료되기 전이다.
"When" 나는 MSFT 주식 20을 팔도록 요청했다.
"Then" 나는 MSFT 주식 80 가지고 있어야 한다.
그리고 나는 APPL 주식 150을 가지고 있어야 한다.
그리고 MSFT 주식 20이 판매 요청이 실행되었어야 한다. 위의 예제는 Cucumber를 사용한 것이다. 이는 BusinessFacingTests를 작성하는 가장 유명한 방법이다. 하지만 Given When Then 방식으로 어떤 종류의 테스트이던지 모두 가능하다. 어떤 사람은 Given-When-Then을 유닛테스트 안에 유용한 정보를 담은 블록으로써 넣는 것을 좋아하거나, 또 그냥 형식이 없는 글의 구조를 위해 이러한 컨벤션을 사용하는 것을 본적도 있다.
나는 전제 조건을 어떻게 명세했는지 설명하기 위해 given을 특징적으로 사용했다. 단지 그렇게 생각하는 것을 선호하기 때문이다. 하지만 테스팅 프레임워크는 given을 when 커멘드를 실행하기 전에 시스템 하에 동작하는 테스트를 올바른 상태로 가져오기 위한 명령어 세트로 해석한다. (이는 왜 "setup"이 다른 네이밍 컨벤션으로 종종 불리는 설명이 된다.) 테스팅 프레임워크는 then 명령어를 위해 다양한 쿼리 메소드를 제공한다. - 이것은 분명 부작용으로 부터 자유로워야 한다.
비록 Given-When-Then 스타일이 BDD의 신호가 보이긴 하지만, 기본적인 아이디어는 테스트를 하거나 예를 들어 구체화할 때 꽤나 보편적이다. Meszaros는 이 패턴을 Four-Phase 테스트라고 설명한다. 그의 네 단계는 Setup (Given), Exercise (When), Verify (Then) and Teardown이다. Bill Wake은 Arrange, Act, Assert 형식이라고 제안하기도 했다.
