BDD-BDD 방식의 TDD
TDD에서 "수락 테스트"라는 용어는 오해의 소지가 있습니다. 수락 테스트는 실제로 시스템의 예상 동작을 나타냅니다. 애자일 관행에서는 전체 팀의 협업과 고객 및 기타 이해 관계자와의 상호 작용이 강조됩니다. 이로 인해 프로젝트에 참여한 모든 사람이 쉽게 이해할 수있는 용어를 사용할 필요가 생겼습니다.
TDD는 필요한 사항에 대해 생각하게합니다. Behavior 따라서 '행동'이라는 용어는 ‘Test’. BDD는 테스트가 아닌 행동에 초점을 맞춘 어휘를 사용하는 테스트 주도 개발입니다.
Dan North의 말에 따르면, "나는 테스트에서 사고에서 행동으로 사고로의 전환이 너무 심해서 TDD를 BDD 또는 행동 주도 개발이라고 부르기 시작했습니다." TDD는 무언가가 작동하는 방식에 초점을 맞추고 BDD는 우리가 그것을 만드는 이유에 초점을 맞 춥니 다.
BDD는 개발자가 자주 직면하는 다음 질문에 답합니다.
| 질문 | 대답 |
|---|---|
| 어디서 시작하나요? | 밖에서 |
| 무엇을 테스트할까요? | 사용자 스토리 |
| 무엇을 테스트하지 말아야합니까? | 다른 것 |
이러한 답변은 다음과 같은 스토리 프레임 워크를 생성합니다.
Story Framework
로 [Role]
내가 원하는 [Feature]
그래서 [Benefit]
이것은 '때 Feature 실행되면 결과 Benefit 연주하는 사람에게 Role.'
BDD는 다음 질문에 추가로 답변합니다.
| 질문 | 대답 |
|---|---|
| 한 번에 얼마나 테스트해야합니까? | 거의 집중하지 않음 |
| 그들의 테스트를 무엇이라고 부를까요? | 문장 템플릿 |
| 테스트가 실패한 이유를 이해하는 방법 | 선적 서류 비치 |
이러한 답변은 다음과 같이 예제 프레임 워크가됩니다.
Example Framework
Given 초기 컨텍스트,
When 이벤트가 발생하면
Then 몇 가지 결과를 보장합니다.
즉, '초기 컨텍스트에서 시작하여 특정 이벤트가 발생하면 결과가 무엇인지 압니다. should be. '
따라서이 예제는 시스템의 예상 동작을 보여줍니다. 예제는 시스템의 다양한 시나리오를 설명하는 데 사용됩니다.
스토리 및 시나리오
ATM 시스템에 대한 Dan North의 다음 그림을 살펴 보겠습니다.
이야기
As a 고객,
I want ATM에서 현금을 인출하려면
so that 은행에서 줄을 서서 기다릴 필요가 없습니다.
시나리오
이 이야기에는 두 가지 가능한 시나리오가 있습니다.
Scenario 1 − 계정이 크레딧에 있음
Given 계좌가 신용 상태입니다
And 카드가 유효합니다
And 디스펜서에 현금이 들어 있습니다
When 고객이 현금을 요청하다
Then 계좌가 인출되었는지 확인
And 현금 지급 확인
And 카드 반환 확인
Scenario 2 − 계정이 초과 인출 한도를 초과하여 인출되었습니다.
Given 계정이 초과 인출되었습니다
And 카드가 유효합니다
When 고객이 현금을 요청하다
Then 거부 메시지가 표시되는지 확인
And 현금이 지급되지 않도록하십시오
And 카드 반환 확인
이벤트는 두 시나리오에서 동일하지만 컨텍스트가 다릅니다. 따라서 결과가 다릅니다.
개발주기
BDD의 개발주기는 outside-in 접근하다.
Step 1− 빨간색으로 변하는 높은 수준의 (외부) 비즈니스 가치 예제 (Cucumber 또는 RSpec / Capybara 사용)를 작성하십시오. (RSpec은 Ruby 언어로 BDD 프레임 워크를 생성합니다)
Step 2 − 빨간색으로 표시되는 구현의 첫 번째 단계에 대한 하위 수준 (내부) RSpec 예제를 작성합니다.
Step 3 − 하위 수준 예제를 통과하기위한 최소 코드를 구현합니다.
Step 4 − 빨간색으로 변하는 1 단계를 통과하는 다음 하위 레벨 RSpec 예제를 작성하십시오.
Step 5 − 1 단계의 상위 수준 예제가 녹색이 될 때까지 3 단계와 4 단계를 반복합니다.
Note − 다음 사항에 유의해야합니다 −
Red/green state는 권한 상태입니다.
하위 수준 테스트가 녹색이면 새 예제를 작성하거나 기존 구현을 리팩터링 할 수있는 권한이 있습니다. 리팩토링의 맥락에서 새로운 기능 / 유연성을 추가해서는 안됩니다.
하위 수준 테스트가 빨간색이면 기존 테스트를 녹색으로 만들기위한 구현 코드 만 작성하거나 변경할 수있는 권한이 있습니다. 존재하지 않는 다음 테스트를 통과하기 위해 코드를 작성하거나 훌륭하다고 생각되는 기능을 구현하려는 충동을 저항해야합니다 (고객이 요청하지 않았을 것임).