[마틴파울러]GivenWhenThen 번역본

원본은 아래 링크를 클릭해주세요.

bliki: GivenWhenThen

Given-When-Then은 SpecificationByExample을 사용하여 시스템의 동작을 지정하는 테스트를 나타내는 스타일입니다 . BDD ( Behavior-Driven Development)의 일부로 Daniel Terhorst-North 와 Chris Matts가 개발 한 접근 방식입니다 . [1] Cucumber와 같은 많은 테스트 프레임 워크에 대한 구조화 접근 방식으로 보입니다. 4 단계 테스트 패턴 의 재구성으로 볼 수도 있습니다 .

기본적인 아이디어는 시나리오 (또는 테스트) 작성을 세 부분으로 나누는 것입니다.

• Given - 당신은 이 시나리오에서 지정하고 있는 동작을 시작하기 전에 상태를 설명합니다. 테스트에 대한 전제 조건으로 생각할 수 있습니다.
• When - 당신이 지정하고 싶은 행동의 영역입니다.
• 마지막으로 Then 에서는 지정된 동작으로 인해 예상되는 변경 사항을 설명합니다.

아래 예시를 통해 이해해봅시다.

Feature: User trades stocks
  Scenario: User requests a sell before close of trading
    Given I have 100 shares of MSFT stock
       And I have 150 shares of APPL stock
       And the time is before close of trading

    When I ask to sell 20 shares of MSFT stock
     
     Then I should have 80 shares of MSFT stock
      And I should have 150 shares of APPL stock
      And a sell order for 20 shares of MSFT stock should have been executed
      
기능 : 사용자의 거래 주식 
  시나리오 : 사용자는 거래의 가까운 전에 판매를 요청 
    내가 MSFT 주식의 백주를 감안할 때 
       내가 APPL 주식 150 주를 가지고 
       그리고 시간 가까이 거래의 이전이다 

    내가 MSFT 주식 20 주를 판매하고 물어 보면 
     
     그런 MSFT 주식 80 주, 
      APPL 주식 150 
      주, MSFT 주식 20 주 매도 주문이 이루어져야합니다.

위의 예는 BusinessFacingTests 를 작성하는 인기있는 방법 인 Cucumber [3] 를 사용하지만 모든 종류의 테스트에서 Given-When-Then 스타일을 사용할 수 있습니다. 어떤 사람들은 Given-When-Then을 주석으로 사용하여 단위 테스트 내에 비공식 블록을 표시하는 것을 좋아합니다 [4] . 비공식 산문을 구성하는 이 관습도 보았습니다.

이 접근 방식에서는 각 절 내에서 여러 식을 결합하는 데 사용되는 "and"를 보는 것이 일반적입니다.

I've characterized the given as a description of the pre-condition state because that's the way I prefer to think of it. A testing framework, however, interprets the givens as a set of commands to bring the system-under-test into the correct state before executing the when command. (Which is why other naming conventions often call this "setup".) Testing frameworks provide various query methods for the then commands - these should be free of side-effects.

사전조건을 설명하는 the given 영역을 특성화시켰습니다. 왜냐하면, 그 방법이 테스트 프레임워크에서 내가 선호하는 방식이기 때문이다. 그러므로, 다수의 the given의 명령어들은 command가 실행되기 전에 sut가 적절한 상태로 되어있는지 해석해줍니다.

(이것이 바로 다른 명명 규칙에서 이것을 "설정"이라고 부르는 이유입니다.) 테스트 프레임 워크는 then 명령에 대한 다양한 쿼리 메서드를 제공합니다. 이러한 메서드는 부작용이 없어야합니다.

Given-When-Then 스타일은 BDD의 증상이지만, 예제로 테스트 또는 사양을 작성할 때 기본 아이디어는 매우 일반적입니다. Meszaros 는 패턴을 Four-Phase Test 로 설명합니다 . 그의 네 단계는 설정 (주어진), 운동 (시기), 확인 (그때) 및 해체 [5] 입니다. Bill Wake는 Arrange, Act, Assert 라는 공식을 내놓았습니다 .

---

1 : 이에 대한 검토 의견에서 Dan은이 문제를 해결하는 데 상당한 영감을 준 Ivan Moore의 공로를 인정합니다.

2 : 에서 피트 호지 슨

3 : 또는 엄격하게하기 위해 Cucumber의 DSL 이름 인 Gherkin을 사용합니다.

4 : 테스트 프레임 워크는 xunit 또는 BDD의 이름 지정 스타일을 따르는 경향이 있으며, 후자는 Given-When-Then 스타일로 메서드 이름을 지정하는 경향이 있습니다.

5 : 테어 다운은 테스트를 구현할 때 항상 필요한 것은 아니며 (특히 Automated Teardown을 사용하는 경우 ) 예제를 통해 사양의 통신 측면에 많은 것을 추가하지 않습니다. 따라서 BDD 스타일에서 누락 된 것을 보는 것이 합리적입니다.