**title**: 반품 및 교환은 재고로 이동합니다.
**as a** 가게 주인으로서,
**I want** 반품 또는 교환 시 상품을 재고에 다시 추가하고 싶습니다.
**so that** 인벤토리를 추적할 수 있습니다.
**Scenario 1:** 환불을 위해 반품된 항목은 인벤토리에 추가되어야 합니다.
**Given** 고객이 이전에 나에게서 검은색 스웨터를 구매했다는 점을 감안할 때
**and** 인벤토리에 검은색 스웨터 3개가 있습니다.
**when** 환불을 위해 검은색 스웨터를 반환할 때
**then** 그러면 인벤토리에 4개의 검은색 스웨터가 있어야 합니다.
Feature > […Scenario] > […Step]
Given: Given단계는 시스템의 초기 컨텍스트( 시나리오 장면) 를 설명하는 데 사용됩니다 . 그것은 일반적으로 과거에 일어난 일입니다.When: When단계는 이벤트 또는 작업 을 설명하는 데 사용됩니다 . 이것은 시스템과 상호 작용하는 사람이거나 다른 시스템에 의해 트리거되는 이벤트일 수 있습니다.Then: Then단계는 예상되는 결과 또는 결과 를 설명하는 데 사용됩니다 .And,But
Scenario: 항목 검색 후 결제 페이지로 이동
Given 사용자가 Greencart 방문 페이지에 있다
When 사용자가 야채<이름>를 검색했을 때
And 장바구니에 항목이 추가된다
And 사용자는 구매를 위해 Checkout 페이지로 이동한다
Then 선택한 <이름> 항목이 체크아웃 페이지에 표시된다
BDD는 무엇을 의미합니까?
BDD는 시스템의 원하는 동작을 협력적으로 지정하는 접근 방식입니다. 행동의 일부가 합의될 때마다 우리는 그 행동을 구현할 코드의 개발을 “추진”하기 위해 해당 사양을 사용합니다.
BDD의 세 가지 관행은 무엇이며 스토리에 어떤 순서로 적용합니까?
우리는 스토리에 필요한 행동의 범위를 공동으로 발견 하는 것으로 시작합니다. 일단 우리가 행동에 동의하면 우리는 비즈니스가 읽을 수 있는 언어로 사양을 공식화 합니다. 마지막으로 공식화된 사양을 자동화 하여 시스템이 실제로 예상대로 작동하는지 확인합니다.
Cucumber와 BDD는 어떤 관련이 있습니까?
Cucumber는 문서를 이해하고 자동화된 테스트로 변환하는 도구입니다.
BDD는 세 가지 방식으로 구성된 협업적 접근 방식입니다. BDD 실무자는 Cucumber를 사용하여 문서를 자동화할 수 있습니다.
“살아있는 문서”의 특별한 점은 무엇입니까?
문서가 애플리케이션의 동작과 동기화되지 않을 때 자동으로 알려 주기 때문에 “살아있는 문서”라고 부릅니다. 그것이 특별한 점입니다.
완료에 대한 정의의 일부로 이를 검토할 수 있지만 자동으로 유효성이 검사되지 않더라도 작성한 모든 사양 문서에 대해서도 마찬가지입니다.
그것은 자동화된 테스트에 의해 생성 되지 않습니다 - 여전히 작성해야 합니다! 자동화된 테스트는 귀하가 작성한 내용이 사실인지 아닌지를 알려줍니다.
이를 위한 변경 제어 프로세스가 있을 수 있습니다. 설명하는 코드와 함께 소스 제어에 유지하는 것이 좋습니다. 그러나 다시 말해서 특별한 것은 아닙니다. Word 문서에 대해 놀랍도록 투명한 변경 제어 프로세스를 가질 수 있지만 여전히 완전히 구식이고 잘못된 것일 수 있습니다.