와우, 그것은 지루한 작은 오이입니다!

이와 같은 작은 오이 시나리오를 본 적이 있습니까?

Scenario: Prime customers shipping is free for Prime items

Given I access URL "https://www.amazon.com"
And I click the "Hello, Sign in" link
And the "Sign-In" page is displayed
When I enter email address "[email protected]"
And I click the "Continue" button
Then the "Password" page is displayed
When I enter email address "donotputpasswordsingherkin"
And I click the "Continue" button
Then I am logged in
And the "Home" page is displayed
When I enter "Crocs that will make me look cool" in the search textbox
And I click the hourglass image
And the search results are displayed
And "Crocs shoes" are displayed on the search results page
And I click on the first item in the search results
And the "Item Detail" page for the selected item is displayed
And I select "13 Women/11 Men" from the size combo box
And the "Inspired By" page is displayed
When I click the "Proceed to Checkout" button
Then the "Checkout" page is displayed
And there is 1 item in the order
And The Shipping & Handling cost for the order is "$0.00"
And I click the "Place your Order" button
And the "Order Placed" page is displayed

"나를 멋져 보이게 해 줄 크록스"를 검색하는 것 외에 이 시나리오에 어떤 문제가 있습니까?

내 역할에서 QA 테스트 자동화에 중점을 두고 고객과 협력하여 자동화된 테스트를 구축합니다. 이러한 테스트는 Gherkin 시나리오에 의해 구동되는 경우가 많으며 위와 같은 시나리오를 본 적이 있습니다.

이 시나리오에 도움이 될 몇 가지 Gherkin 규칙이 있습니다.

규칙 1 - 시나리오를 작성할 때 선언적 구문 사용

BDD(Behavior Driven Design) 및 Gherkin의 일반적인 목표 중 하나는 비즈니스 이해 관계자와 개발 팀 간의 커뮤니케이션을 용이하게 하는 메커니즘을 제공하는 것입니다. 이러한 시나리오의 목표는 비즈니스에서 이해하는 도메인 언어로 비즈니스 규칙을 설명하는 것입니다.

위의 시나리오는 명령형 통신 스타일을 사용합니다. 이 예에서는 시나리오를 사용하여 사용자가 수행하는 작업 대신 작업을 완료하는 방법을 설명합니다. 이로 인해 설명되는 비즈니스 규칙에 대한 명확한 방향 없이 작업 목록이 길어질 수 있습니다. 여기서 설명하는 규칙은 무엇입니까? 많은 것 같습니다! (규칙 2 참조)

또 다른 단점은 읽고 확인하는 것이 매우 고통스럽다는 것입니다. 이와 같은 30개의 시나리오를 검토하는 QA, 개발자 및 이해 관계자와의 2시간 회의를 상상해 보십시오. 그들은 지루하고 따라가기 어렵고 무시하기 쉽습니다.

선언적 언어를 사용하면 사용자가 수행하는 방법을 설명하지 않고도 사용자가 수행하는 작업을 설명할 수 있습니다. 시나리오에서 단추와 텍스트 상자를 참조하는 경우 다른 옵션을 고려하십시오. 실제로 응용 프로그램을 전혀 참조하지 않고 비즈니스 규칙을 설명한다고 상상해 보십시오. 예를 들어 처음 11줄을 한 줄로 바꿀 수 있습니다.

Given a Prime customer is authenticated

규칙 2 - 시나리오당 단 하나의 When/Then 조합

위의 시나리오를 보면 하나의 동작을 설명하는 대신 종단 간 시나리오를 설명하고 있음이 분명합니다. BDD를 사용하면 단일 동작을 설명하는 하나의 시나리오가 필요하며 이는 단일 When/Then 조합이 필요함을 의미합니다. "언제"는 사용자 상호 작용을 설명하고 "다음"은 예상 결과를 설명합니다. 따라서 문제는 이 시나리오에서 어떤 행동을 설명하고 있는가입니다.

말하기 어렵다. "때"와 "그때"가 많이 있지만 시나리오 설명을 보면 "프라임 고객 배송은 프라임 품목에 대해 무료입니다"라고 표시됩니다. 이것이 우리가 설명하고자 하는 비즈니스 규칙이라고 가정해 봅시다. 그래서 이것을 시도해 봅시다:

Scenario: Prime customers shipping is free for Prime items

Given a Prime customer is authenticated
When the authenticated customer enters checkout with a single Prime item
Then the shipping is free

어떻게한다는거야? 확실히 읽기가 훨씬 쉽고 비즈니스 규칙이 무엇인지 매우 명확하며 예상대로 작동하는지 확인하기 위한 구체적인 예를 제공합니다.

또한 비즈니스 규칙에 집중하면 필요한 다른 사항을 볼 수 있습니다.

상품이 프라임 대상이 아니면 어떻게 됩니까? 이를 위한 시나리오가 필요합니다.

프라임 아이템이 여러 개라면? 이를 위한 시나리오가 필요합니다.

주문이 프라임 및 비프라임 아이템의 조합인 경우 어떻게 됩니까? 이를 위한 시나리오가 필요합니다.

고객이 Prime 고객이 아니면 어떻게 됩니까? 이를 위한 시나리오가 필요합니다.

마무리

Gherkin을 작성하기 위한 규칙과 표준은 실제로 꽤 논쟁의 여지가 있는 주제일 수 있습니다. 새 프로젝트를 시작하는 경우 지금이 프로젝트에서 BDD와 Gherkin을 어떻게 사용할 것인지에 대한 합의에 도달할 때입니다.

프로젝트가 순조롭게 진행되고 있고 이러한 단계를 자동화하기 위한 자동화 프레임워크의 지원을 받는 많은 명령형/절차적 시나리오가 있는 경우 변경하기가 더 어려울 것입니다.

이러한 상황에서 베이비 스텝을 사용하면 선언적 구문으로 새 시나리오를 작성하는 데 동의할 수 있습니다. 테스트 자동화의 경우 여러 절차적 단계를 단일 선언적 단계로 추상화하고 자동화 단계를 내부에서 계속 사용할 수 있습니다.

그리고 여전히 확신이 서지 않는다면 시나리오 검토 회의가 얼마나 더 즐거울지 상상해 보십시오!