행동 기반 개발-퀵 가이드

행동 기반 개발 (BDD)은 원래 TDD (Test Driven Development)에서 나온 소프트웨어 개발 프로세스입니다.

BDD의 발전을 책임지고있는 Dan North에 따르면,“BDD는 중요한 소프트웨어를 제공하기 위해 공유 된 이해와 표면 불확실성을 생성하기 위해 여러 수준에서 예제를 사용하고 있습니다.”

BDD는 개발에 관련된 모든 사람이 읽을 수 있고 이해할 수있는 언어로 작성된 시스템의 동작을 설명하기 위해 예제를 사용합니다. 이러한 예는 다음과 같습니다.

실행 가능한 사양으로 변환됩니다.
수락 테스트로 사용됩니다.

BDD – 주요 기능

행동 기반 개발은 다음에 초점을 둡니다.

비즈니스 가치가있는 제품을 제공 할 목적으로 소프트웨어 개발자, 비즈니스 분석가 및 이해 관계자와의 커뮤니케이션을 촉진하는 공유 프로세스 및 공유 도구를 제공하여 소프트웨어 개발에 협력합니다.
시스템이 수행해야하는 작업 및 구현 방법이 아닙니다.
더 나은 가독성과 가시성을 제공합니다.
소프트웨어의 작동뿐만 아니라 고객의 기대에 부합하는지 확인합니다.

BDD의 기원

결함이 적시에 감지되지 않고 감지되는 즉시 수정되면 결함을 수정하는 비용이 여러 배로 증가합니다. 다음 예를 고려하십시오.

이는 요구 사항을 올바르게 획득하지 않으면 이후 단계에서 요구 사항을 오해하여 발생하는 결함을 수정하는 데 비용이 많이 든다는 것을 보여줍니다. 또한 최종 제품이 고객의 기대를 충족하지 못할 수 있습니다.

시간의 필요성은 다음과 같은 개발 접근 방식입니다.

요구 사항을 기반으로합니다.
개발 전반에 걸친 요구 사항에 중점을 둡니다.
요구 사항이 충족되었는지 확인합니다.

위에서 언급 한 요구 사항을 처리 할 수있는 개발 방식은 BDD입니다. 따라서 행동 주도 개발-

시스템의 다양한 예상 동작의 예를 도출합니다.
고객을 포함하여 개발에 관련된 모든 사람이 쉽게 이해할 수 있도록 비즈니스 도메인 용어를 사용하여 언어로 예제를 작성할 수 있습니다.
대화를 통해 수시로 고객과 승인 된 예를 가져옵니다.
개발 전반에 걸쳐 고객 요구 사항 (예제)에 중점을 둡니다.
수락 테스트로 예제를 사용합니다.

BDD 관행

BDD의 두 가지 주요 관행은-

예제 별 사양 (SbE)
테스트 주도 개발 (TDD)

예별 사양

SbE (Specification by Example)는 대화에서 예제를 사용하여 빌드 할 소프트웨어의 비즈니스 규칙과 동작을 설명합니다.

예제 별 사양을 통해 제품 소유자, 비즈니스 분석가, 테스터 및 개발자는 비즈니스 요구 사항에 대한 일반적인 오해를 제거 할 수 있습니다.

테스트 주도 개발

BDD의 맥락에서 Test Driven Development는 예제를 사람이 읽을 수 있고 실행 가능한 사양으로 변환합니다.

개발자는 이러한 사양을 지침으로 사용하여 새로운 기능을 구현합니다. 그 결과 소프트웨어 수명 내내 유지 관리 비용을 낮게 유지하는 린 코드베이스와 자동화 된 회귀 테스트 제품군이 생성됩니다.

애자일 BDD

애자일 소프트웨어 개발에서 BDD 방법은 보류중인 사양에 대한 공통된 이해를 얻기 위해 사용됩니다.

다음 단계는 Agile BDD에서 실행됩니다-

개발자와 제품 소유자는 일반 텍스트 편집기에서 보류중인 사양을 공동으로 작성합니다.
제품 소유자는 시스템에서 기대하는 동작을 지정합니다.
개발자
- 이러한 동작 세부 사항으로 사양을 채우십시오.
- 시스템에 대한 이해를 바탕으로 질문하십시오.
현재 시스템 동작은 새 기능이 기존 기능을 중단하는지 확인하기 위해 고려됩니다.

Agile Manifesto 및 BDD

Agile Manifesto는 다음과 같이 말합니다.

우리는 소프트웨어를 개발하고 다른 사람들이 그렇게하도록 도와줌으로써 더 나은 소프트웨어 개발 방법을 찾고 있습니다. 이 작업을 통해 우리는 가치를 얻었습니다.

Individuals and interactions − 프로세스 및 도구
Working software − 포괄적 인 문서
Customer collaboration − 계약 협상
Responding to change − 계획을 따름

즉, 오른쪽 항목에는 가치가 있지만 왼쪽 항목에는 더 가치가 있습니다.

BDD는 다음과 같이 Agile 선언문에 따라 정렬됩니다.

애자일 선언	BDD 정렬
프로세스 및 도구에 대한 개인 및 상호 작용.	BDD는 대화를 나누는 것입니다.
포괄적 인 문서에 대한 작업 소프트웨어.	BDD는 비즈니스 가치가있는 소프트웨어를 쉽게 만드는 데 중점을 둡니다.
계약 협상을 통한 고객 협력.	BDD는 개발이 진행됨에 따라 고객과 지속적인 커뮤니케이션을 통해 아이디어를 기반으로 한 시나리오에 중점을 둡니다. 약속에 근거한 것이 아닙니다.
계획에 따라 전환에 응답합니다.	BDD는 변화의 흡수를 촉진하는 지속적인 커뮤니케이션과 협업에 중점을 둡니다.

행동 기반 개발에 대한 참조를 보면 "BDD는 TDD에서 파생 됨", "BDD 및 TDD"와 같은 구문의 사용을 찾을 수 있습니다. BDD가 어떻게 생겨 났는지, 왜 TDD에서 파생되었다고하는지, BDD와 TDD가 무엇인지 알기 위해서는 TDD에 대한 이해가 필요합니다.

왜 테스트 하는가?

시작하려면 테스트의 기초를 살펴 보겠습니다. 테스트의 목적은 빌드 된 시스템이 예상대로 작동하는지 확인하는 것입니다. 다음 예를 고려하십시오.

따라서 경험을 통해 결함이 도입되는 즉시 발견하고 즉시 수정하는 것이 비용 효율적이라는 것을 배웠습니다. 따라서 개발 및 테스트의 모든 단계에서 테스트 케이스를 작성해야합니다. 이것은 우리의 전통적인 테스트 관행이 우리에게 가르쳐 준 것이며, 종종 Test-early라고 불립니다.

이 테스트 접근 방식은 테스트가 단계 완료 후 수행되므로 테스트-마지막 접근 방식이라고합니다.

테스트-마지막 접근 방식의 과제

Test-Last 접근 방식은 소프트웨어 개발 프로젝트에서 꽤 오랜 시간 동안 따랐습니다. 그러나 실제로 이러한 접근 방식을 사용하면 테스트가 특정 단계가 완료 될 때까지 기다려야하기 때문에 종종 간과되는 이유는 다음과 같습니다.

무대 완료 지연.
빡빡한 시간표.
테스트를 건너 뛰고 정시에 전달하는 데 집중합니다.

또한 Test-Last 접근 방식에서는 개발자가 수행해야하는 단위 테스트를 건너 뛰는 경우가 많습니다. 발견 된 다양한 이유는 개발자의 사고 방식에 기반합니다.

그들은 개발자이지 테스터가 아닙니다.
테스트는 테스터의 책임입니다.
코딩이 효율적이고 코드에 결함이 없습니다.

결과는-

제공되는 제품의 품질 저하.
테스터에게만 품질에 대한 책임이 있습니다.
결함 수정, 배송 후 비용이 많이 듭니다.
고객 만족도를 얻지 못함은 반복적 인 비즈니스 손실을 의미하므로 신뢰성에 영향을 미칩니다.

이러한 요인은 테스트에 초점을 맞추기 위해 패러다임의 전환을 요구했습니다. 그 결과는 Test-First 접근 방식이었습니다.

테스트 우선 접근 방식

Test-First 접근 방식은 인사이드 아웃 (코드 작성 후 테스트)을 아웃 사이드 인 (테스트 작성 후 코드 작성) 개발 방식으로 대체합니다.

이 접근 방식은 다음과 같은 소프트웨어 개발 방법론에 통합되어 있습니다 (즉, Agile이기도합니다).

이자형X떨다 P로그 래밍 (XP).
T동부 표준시 DRiven D개발 (TDD).

이러한 방법론에서 개발자는 코드 모듈의 한 줄을 작성하기 전에 코드 모듈에 대한 단위 테스트를 설계하고 작성합니다. 그런 다음 개발자는 단위 테스트 통과를 목표로 코드 모듈을 만듭니다. 따라서 이러한 방법론은 단위 테스트를 사용하여 개발을 추진합니다.

목표가 테스트를 기반으로 한 개발이라는 점에 주목해야 할 기본 사항입니다.

빨강-녹색-리팩터링주기

테스트 주도 개발은 단위 테스트에서 안내하는 코드를 개발하는 데 사용됩니다.

Step 1 − 작성 될 코드 모듈을 고려하십시오.

Step 2 − 테스트 작성

Step 3 − 테스트를 실행합니다.

코드가 아직 작성되지 않았기 때문에 테스트가 실패합니다. 따라서 2 단계는 일반적으로 실패 할 테스트 작성이라고합니다.

Step 4 − 테스트를 통과 할 수있는 최소한의 코드를 작성하십시오.

Step 5− 모든 테스트를 실행하여 모두 통과하는지 확인하십시오. 이 단계를 용이하게하기 위해 단위 테스트가 자동화됩니다.

Step 6 − 리팩터링.

Step 7 − 다음 코드 모듈에 대해 단계 1 ~ 단계 6을 반복합니다.

각주기는 매우 짧아야하며 일반적인 시간에는 많은주기가 포함되어야합니다.

이것은 또한 널리 알려진 Red-Green-Refactor 사이클, 여기서-

Red − 실패한 테스트 작성.
Green − 테스트를 통과하기위한 코드 작성.
Refactor − 중복을 제거하고 코드를 허용 가능한 표준으로 개선합니다.

TDD 프로세스 단계

TDD 프로세스의 단계는 다음과 같습니다.

TDD의 장점

테스트 주도 개발의 이점 또는 이점은 다음과 같습니다.

개발자는 먼저 코드를 작성하기 전에 원하는 결과가 무엇인지, 테스트 방법을 이해해야합니다.
구성 요소에 대한 코드는 테스트를 통과하고 코드가 리팩터링 될 때만 완료됩니다. 이렇게하면 개발자가 다음 테스트로 이동하기 전에 테스트 및 리팩토링이 보장됩니다.
각 리팩토링 후에 단위 테스트 모음이 실행되므로 각 구성 요소가 여전히 작동하고 있다는 피드백은 일정합니다.
단위 테스트는 항상 데이터에 의존하는 살아있는 문서 역할을합니다.
결함이 발견되면 개발자는 해당 결함을 표시하는 테스트를 만든 다음 테스트를 통과하고 결함이 수정되도록 코드를 수정합니다. 이것은 디버깅 시간을 줄여줍니다. 다른 모든 테스트도 실행되며 통과시 기존 기능이 손상되지 않도록합니다.
개발자는 언제든지 디자인 결정을 내리고 리팩토링 할 수 있으며 테스트를 실행하면 시스템이 계속 작동하는지 확인할 수 있습니다. 이것은 소프트웨어를 유지 보수 할 수있게합니다.
개발자는 변경 사항이 기존 기능에 영향을 미치는 경우 테스트를 실행하여 동일한 내용이 드러나고 결함을 즉시 수정할 수 있으므로 변경할 수 있다는 확신이 있습니다.
각각의 연속 테스트 실행에서 이전의 모든 결함 수정 사항도 확인되고 동일한 결함의 반복이 감소합니다.
대부분의 테스트는 개발 자체에서 이루어지기 때문에 배송 전 테스트가 단축됩니다.

TDD의 단점

시작점은 시스템의 동작을 설명하는 사용자 스토리입니다. 따라서 개발자는 종종 다음과 같은 질문에 직면합니다.

언제 테스트할까요?
무엇을 테스트할까요?
사양이 충족되는지 어떻게 알 수 있습니까?
코드가 비즈니스 가치를 제공합니까?

TDD에 대한 오해

다음과 같은 오해가 업계에 존재하며 설명이 필요합니다.

오인	설명
TDD는 테스트 및 테스트 자동화에 관한 것입니다.	TDD는 Test-First 접근 방식을 사용하는 개발 방법론입니다.
TDD는 어떤 디자인도 포함하지 않습니다.	TDD에는 요구 사항에 따른 중요한 분석 및 설계가 포함됩니다. 디자인은 개발 중에 나타납니다.
TDD는 단위 수준에만 있습니다.	TDD는 통합 및 시스템 수준에서 사용할 수 있습니다.
TDD는 기존 테스트 프로젝트에서 사용할 수 없습니다.	TDD는 Extreme Programming에서 인기를 얻었으며 다른 Agile 방법론에서도 사용되고 있습니다. 그러나 기존 테스트 프로젝트에서도 사용할 수 있습니다.
TDD는 도구입니다.	TDD는 개발 방법론이며, 새로운 단위 테스트가 통과 할 때마다 새로운 코드가 추가되거나 기존 코드가 수정 될 때마다 그리고 모든 리팩토링 후에 모든 테스트가 실행되어야하므로 자동화 테스트 스위트에 추가됩니다. 따라서 TDD를 지원하는 테스트 자동화 도구는이 프로세스를 용이하게합니다.
TDD는 수락 테스트를 개발자에게 전달하는 것을 의미합니다.	TDD는 개발자에게 수락 테스트를 전달하는 것을 의미하지 않습니다.

수락 TDD

ATDD (Acceptance Test Driven Development)는 개발 초기에 사용자 스토리를 생성하는 동안 수락 기준 및 수락 테스트를 정의합니다. ATDD는 고객, 개발자 및 테스터 간의 의사 소통 및 공통 이해에 중점을 둡니다.

ATDD의 주요 사례는 다음과 같습니다.

실제 시나리오를 논의하여 도메인에 대한 공통된 이해를 구축하십시오.
이러한 시나리오를 사용하여 허용 기준에 도달하십시오.
수락 테스트를 자동화합니다.
이러한 테스트에 개발에 집중하십시오.
테스트를 라이브 사양으로 사용하여 변경을 용이하게합니다.

ATDD 사용의 이점은 다음과 같습니다.

요구 사항은 명확하고 기능적 차이가 없습니다.
다른 사람들은 개발자가 예상하는 특별한 경우를 이해합니다.
수락 테스트는 개발을 안내합니다.

TDD 대 BDD

Dan North에 따르면 프로그래머는 일반적으로 Test Driven Development를 수행하는 동안 다음과 같은 문제에 직면합니다.

어디서 시작하나요
테스트 할 항목과 테스트하지 않을 항목
한 번에 테스트 할 양
그들의 테스트를 부르는 것
테스트가 실패한 이유를 이해하는 방법

이러한 모든 문제에 대한 해결책은 행동 기반 개발입니다. 기존의 애자일 관행에서 발전했으며 애자일 소프트웨어 제공을 처음 접하는 팀이 더 쉽게 접근하고 효과적으로 사용할 수 있도록 설계되었습니다. 시간이 지남에 따라 BDD는 애자일 분석 및 자동화 된 승인 테스트의 광범위한 그림을 포함하도록 성장했습니다.

메인 difference between TDD and BDD -

TDD는 소프트웨어 작동 방식을 설명합니다.
반면에 BDD-
- 최종 사용자가 소프트웨어를 사용하는 방법을 설명합니다.
- 협업 및 커뮤니케이션을 촉진합니다.
- 시스템 동작의 예를 강조합니다.
- 예제에서 파생 된 실행 가능한 사양을 목표로합니다.

TDD에서 "수락 테스트"라는 용어는 오해의 소지가 있습니다. 수락 테스트는 실제로 시스템의 예상 동작을 나타냅니다. Agile 관행에서는 전체 팀의 협업과 고객 및 기타 이해 관계자와의 상호 작용이 강조됩니다. 이로 인해 프로젝트에 참여한 모든 사람이 쉽게 이해할 수있는 용어를 사용해야합니다.

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는 권한 상태입니다.
하위 수준 테스트가 녹색이면 새 예제를 작성하거나 기존 구현을 리팩터링 할 수있는 권한이 있습니다. 리팩토링의 맥락에서 새로운 기능 / 유연성을 추가해서는 안됩니다.
하위 수준 테스트가 빨간색이면 기존 테스트를 녹색으로 만들기 위해서만 구현 코드를 작성하거나 변경할 수있는 권한이 있습니다. 존재하지 않는 다음 테스트를 통과하기 위해 코드를 작성하거나 훌륭하다고 생각하는 기능을 구현하려는 충동을 저항해야합니다 (고객이 요청하지 않았을 것입니다).

'Specification by Example'의 저자 인 Gojko Adzic에 따르면, Specification by Example은 올바른 제품이 효율적으로 제공되도록 소프트웨어 제품의 변경을 촉진하는 일련의 프로세스 패턴입니다.”

예제 별 사양은 추상적 인 설명 대신 현실적인 예제를 사용하여 요구 사항을 캡처하고 설명하는 것을 기반으로 소프트웨어 제품에 대한 요구 사항 및 비즈니스 지향 기능 테스트를 정의하는 공동 접근 방식입니다.

예제 별 사양 – 개요

예제 별 사양의 목표는 우선 순위가 지정되고 검증 가능한 비즈니스 요구 사항의 개발 및 제공에 초점을 맞추는 것입니다. 사례 별 사양의 개념 자체는 비교적 새로운 것이지만 기존 관행을 단순히 재구성 한 것입니다.

유비쿼터스 언어로 알려진 매우 구체적이고 간결한 어휘를 지원합니다.

실행 가능한 요구 사항을 활성화합니다.
팀의 모든 사람이 사용합니다.
교차 기능 팀이 만듭니다.
모든 사람의 이해를 포착합니다.

예제 별 사양은 비즈니스 도메인을 반영하는 자동화 테스트 구축에 직접 입력으로 사용할 수 있습니다. 따라서 예제 별 사양의 초점은 올바른 제품을 구축하고 제품을 올바르게 구축하는 것입니다.

예제 별 사양 목적

예제 별 사양의 주요 목표는 올바른 제품을 만드는 것입니다. 그것은 공유 된 이해에 초점을 맞추고, 따라서 단일 진실의 근원을 확립합니다. 허용 기준을 자동화하여 결함 감지가 아닌 결함 예방에 초점을 맞 춥니 다. 또한 결함을 조기에 발견하기 위해 조기에 테스트를 진행합니다.

SbE 사용

예제 별 사양은 비즈니스 가치를 설명하는 예상 시스템 동작을 설명하는 데 사용됩니다. 그림은 구체적이고 실제적인 예입니다. 이 예제는 다음과 같은 실행 가능한 요구 사항을 만드는 데 사용됩니다.

번역없이 테스트 가능.
라이브 문서에 캡처되었습니다.

다음은 특정 사양을 설명하기 위해 예제를 사용하는 이유입니다.

이해하기 더 쉽습니다.
오해하기가 더 어렵습니다.

SbE의 장점

예제에 의한 사양 사용의 장점은 다음과 같습니다.

품질 향상
낭비 감소
생산 결함의 위험 감소
집중된 노력
보다 안전하게 변경할 수 있습니다.
비즈니스 참여 향상

SbE의 응용

예에 의한 사양-

복잡한 비즈니스 또는 복잡한 조직.
순전히 기술적 인 문제에 대해서는 잘 작동하지 않습니다.
UI 중심 소프트웨어 제품에서는 잘 작동하지 않습니다.
레거시 시스템에도 적용 할 수 있습니다.

SbE 및 수락 테스트

수락 테스트 측면에서 예제 별 사양의 장점은 다음과 같습니다.

세부 요구 사항 및 테스트에 하나의 그림이 사용됩니다.
프로젝트의 진행은 수락 테스트 측면에서-
- 각 테스트는 동작을 테스트하는 것입니다.
- 테스트는 동작에 대해 통과하거나 통과하지 않습니다.
- 통과 테스트는 특정 동작이 완료되었음을 나타냅니다.
- 100 개의 행동을 완료해야하는 프로젝트에 60 개의 행동이 완료되면 60 %가 완료된 것입니다.
테스터는 결함 수정에서 결함 방지로 전환하고 솔루션 설계에 기여합니다.
자동화를 통해 요구 사항 변경이 솔루션에 미치는 영향을 즉시 이해할 수 있습니다.

예제 별 사양 – 다른 역할에 대한 의미

사례 별 사양의 목표는 비즈니스 가치를 제공하기 위해 프로젝트 전반에 걸쳐 고객을 포함하여 팀의 모든 사람이 협력하도록하는 것입니다. 더 나은 이해를 위해 모든 사람은 동일한 어휘를 사용합니다.

역할	SbE 사용
비즈니스 분석가	요구 사항은 명확하고 기능적 차이가 없습니다. 개발자는 실제로 사양을 읽습니다.
개발자	개발자는 개발중인 내용을 더 잘 이해합니다. 올바르게 개발 된 사양을 세어 개발 진행 상황을 더 잘 추적합니다.
시험 장치	테스터는 테스트 대상을 더 잘 이해합니다. 테스터는 처음부터 참여하고 설계에서 역할을합니다. 테스터는 결함 감지보다는 결함 예방을 위해 노력합니다.
여러분	처음부터 오류를 식별하여 시간을 절약합니다. 처음부터 양질의 제품이 생산됩니다.

SbE – 일련의 프로세스 패턴

이 장의 시작 부분에서 살펴본 것처럼 예제 별 사양은 올바른 제품이 효율적으로 제공되도록 소프트웨어 제품의 변경을 용이하게하는 일련의 프로세스 패턴으로 정의됩니다.

프로세스 패턴은-

협업 사양
예제를 사용하여 사양 설명
사양 수정
자동화 예제
자주 확인
살아있는 문서

협업 사양

협업 사양의 목표는 다음과 같습니다.

공통된 이해와 공유 된 어휘를 갖기 위해 팀에서 다양한 역할을 얻으십시오.
모든 사람이 프로젝트에 참여하도록하여 기능에 대한 서로 다른 관점을 제공 할 수 있도록합니다.
기능의 공유 및 소유권을 보장합니다.

이러한 목표는 Three Amigos 회의라고도하는 사양 워크숍에서 충족됩니다. Three Amigos는 BA, QA 및 개발자입니다. 프로젝트에 다른 역할이 있지만이 세 가지 역할은 정의부터 기능 제공까지 책임이 있습니다.

During the meeting −

비즈니스 분석가 (BA)는 새로운 기능에 대한 요구 사항과 테스트를 제시합니다.
세 명의 Amigos (BA, Developer 및 QA)는 새로운 기능에 대해 논의하고 사양을 검토합니다.
QA와 개발자는 누락 된 요구 사항도 식별합니다.
세 명의 아미고
- 유비쿼터스 언어를 사용하여 공유 모델을 활용합니다.
- 도메인 어휘를 사용합니다 (필요한 경우 용어집이 유지됨).
- 차이점과 갈등을 찾으십시오.
이 시점에서 구현 세부 사항으로 이동하지 마십시오.
기능이 충분히 지정되었는지에 대한 합의에 도달하십시오.
요구 사항과 테스트 소유권을 공유하여 품질 사양을 용이하게합니다.
요구 사항은 명시적이고 명확한 요구 사항을 제공하는 시나리오로 제공됩니다. 시나리오는 사용자 관점에서 시스템 동작의 예입니다.

예제를 사용하여 사양 설명

시나리오는 Given-When-Then 구조를 사용하여 지정되어 테스트 가능한 사양을 생성합니다.

Given <일부 전제 조건>

And <추가 전제 조건> Optional

When <동작 / 트리거 발생>

Then <일부 포스트 조건>

And <추가 포스트 조건> Optional

이 사양은 시스템 동작의 예입니다. 또한 시스템의 수락 기준을 나타냅니다.

팀은 예제를 논의하고 예제가 기능의 예상 동작을 포함한다는 합의가있을 때까지 피드백을 통합합니다. 이것은 좋은 테스트 범위를 보장합니다.

사양 수정

사양을 구체화하려면

예제를 정확하게 작성하십시오. 예제가 복잡해지면 더 간단한 예제로 분할하십시오.
비즈니스 관점에 초점을 맞추고 기술적 세부 사항을 피하십시오.
긍정적이고 부정적인 조건을 모두 고려하십시오.
도메인 별 어휘를 준수하십시오.
고객과 사례를 논의하십시오.
- 이를 위해 대화를 선택하십시오.
- 고객이 관심있는 예제 만 고려하십시오. 이렇게하면 필요한 코드 만 생성 할 수 있으며 필요하지 않을 수있는 가능한 모든 조합을 포함하지 않습니다.
시나리오가 통과하는지 확인하려면 해당 시나리오의 모든 테스트 사례가 통과해야합니다. 따라서 사양을 개선하여 테스트 가능하게 만드십시오. 테스트 케이스에는 다양한 범위 및 데이터 값 (경계 및 코너 케이스)은 물론 데이터 변경을 초래하는 다양한 비즈니스 규칙이 포함될 수 있습니다.
복잡한 계산, 데이터 조작 / 변환 등과 같은 추가 비즈니스 규칙을 지정합니다.
비 기능적 시나리오 (예 : 성능,로드, 유용성 등)를 예제 별 사양으로 포함

자동화 예제

자동화 계층은 매우 단순하게 유지되어야합니다. 테스트중인 시스템에 사양을 배선하기 만하면됩니다. 같은 도구를 사용할 수 있습니다.

DSL (Domain Specific Language)을 사용하여 테스트 자동화를 수행하고 입력과 출력 간의 명확한 연결을 보여줍니다. 스크립트가 아닌 사양에 중점을 둡니다. 테스트가 정확하고 이해하기 쉬우 며 테스트 가능한지 확인하십시오.

자주 검증

모든 변경 (추가 / 수정)과 함께 개발 파이프 라인에 예제 유효성 검사를 포함합니다. 제품의 품질을 보장하기 위해 채택 할 수있는 (그리고 채택해야하는) 많은 기술과 도구가 있습니다. 세 가지 주요 원칙을 중심으로합니다.Test Early, Test Well 과 Test Often.

취약한 링크를 식별 할 수 있도록 자주 테스트를 실행하십시오. 동작을 나타내는 예제는 진행 상황을 추적하는 데 도움이되며 동작은 해당 테스트를 통과 한 후에 만 완료된다고합니다.

살아있는 문서

사양은 가능한 한 간단하고 짧게 유지하십시오. 사양을 구성하고 작업이 진행됨에 따라 발전시킵니다. 팀의 모든 사람이 문서에 액세스 할 수 있도록합니다.

예제 프로세스 단계에 의한 사양

그림은 예제 별 사양의 프로세스 단계를 보여줍니다.

안티 패턴

안티 패턴은 나쁜 프로그래밍 관행으로 간주되는 소프트웨어 개발의 특정 패턴입니다. 공식화되고 일반적으로 좋은 개발 관행으로 간주되는 일반적인 문제에 대한 일반적인 접근 방식 인 디자인 패턴과는 달리, 안티 패턴은 반대이며 바람직하지 않습니다.

안티 패턴은 다양한 문제를 일으 킵니다.

안티 패턴	문제점
협업 없음	많은 가정 잘못된 것을 구축 잘못된 테스트 코드가 완료되면 인식하지 못함
코드가 완료되면 인식하지 못함	테스트 유지하기 어려움 이해하기 어려운 사양 비즈니스 담당자의 관심 상실
너무 상세하거나 UI 중심의 예	테스트 유지하기 어려움 이해하기 어려운 사양 비즈니스 담당자의 관심 상실
필요한 노력을 과소 평가	팀은 실패했다고 생각하고 일찍 실망합니다.

문제 해결-품질

안티 패턴에 시계를 유지하여 품질을 보장 할 수 있습니다. 안티 패턴으로 인한 문제를 최소화하려면 다음을 수행해야합니다.

함께 모여 예제를 사용하여 지정하십시오.
예제를 정리하고 개선하십시오.
예제를 만족하는 코드 작성
예제를 자동화하고 배포합니다.
모든 사용자 스토리에 대해 접근 방식을 반복하십시오.

안티 패턴으로 인한 문제를 해결하려면 다음을 준수해야합니다.

Collaboration.
무엇에 집중합니다.
비즈니스에 집중.
준비하십시오.

위의 각각이 무엇을 의미하는지 이해합시다.

협동

협력-

비즈니스맨, 개발자 및 테스터는 자신의 관점에서 의견을 제공합니다.
자동화 된 예제는 팀이 올바른 것을 구축했음을 증명합니다.
프로세스는 테스트 자체보다 더 가치가 있습니다.

무엇에 집중

'무엇'이라는 질문에 집중해야합니다. '무엇'에 집중하면서-

가능한 모든 경우를 다루려고하지 마십시오.
다른 종류의 테스트를 사용하는 것을 잊지 마십시오.
가능한 한 간단한 예를 유지하십시오.
예제는 시스템 사용자가 쉽게 이해할 수 있어야합니다.
도구는 워크숍에서 중요한 역할을해서는 안됩니다.

비즈니스에 집중

비즈니스에 집중하려면-

비즈니스 의도에 따라 사양을 유지하십시오.
사양을 만들고 검토 할 때 비즈니스를 포함합니다.
자동화 레이어의 모든 세부 정보를 숨 깁니다.

준비하라

다음에 대비하십시오-

팀 관행이 변경되는 동안에도 이점은 즉시 드러나지 않습니다.
SbE를 소개하는 것은 어렵습니다.
시간과 투자가 필요합니다.
자동 테스트는 무료가 아닙니다.

도구

도구 사용은 실제로 여러 도구를 사용할 수 있지만 예제 별 사양에는 필수가 아닙니다. 도구를 사용하지 않아도 Example by Specification에 성공한 경우가 있습니다.

다음 도구는 예제로 사양을 지원합니다-

Cucumber
SpecFlow
Fitnesse
Jbehave
Concordion
Behat
Jasmine
Relish
Speclog

개발 팀은 종종 BDD가 도구 프레임 워크라는 오해를 가지고 있습니다. 실제로 BDD는 도구 프레임 워크가 아닌 개발 접근 방식입니다. 그러나 다른 개발 방식의 경우와 마찬가지로 BDD 용 도구도 있습니다.

다양한 플랫폼 및 프로그래밍 언어에 여러 BDD 도구가 사용됩니다. 그들은-

오이 (Ruby 프레임 워크)
SpecFlow (.NET 프레임 워크)
Behave (Python 프레임 워크)
JBehave (Java 프레임 워크)
JBehave Web (Selenium이 통합 된 자바 프레임 워크)
Lettuce (Python 프레임 워크)
Concordion (Java 프레임 워크)
Behat (PHP 프레임 워크)
Kahlan (PHP 프레임 워크)
DaSpec (JavaScript 프레임 워크)
Jasmine (JavaScript 프레임 워크)
Cucumber-js (자바 스크립트 프레임 워크)
Squish GUI 테스터 (JavaScript, Python, Perl, Ruby 및 Tcl 용 BDD GUI 테스트 도구)
Spock (Groovy 프레임 워크)
Yadda (Jasmine (JavaScript 프레임 워크)와 같은 프레임 워크에 대한 Gherkin 언어 지원)

오이

Cucumber는 전 세계적으로 사용되는 실행 가능한 사양을위한 무료 도구입니다. Cucumber를 사용하면 소프트웨어 개발 팀이 소프트웨어가 일반 텍스트로 어떻게 작동해야하는지 설명 할 수 있습니다. 텍스트는 비즈니스에서 읽을 수있는 도메인 별 언어로 작성되며 문서화, 자동화 된 테스트 및 개발 지원으로 모두 하나의 형식으로 롤링됩니다. Cucumber에서는 40 개 이상의 다른 음성 언어 (영어, 중국어 등)를 사용할 수 있습니다.

오이 – 주요 기능

오이의 주요 기능은 다음과 같습니다.

Cucumber는 실행 가능 사양, 테스트 자동화 및 살아있는 문서화에 사용할 수 있습니다.
Cucumber는 Ruby, Java, NET, Flex 또는 모든 언어로 작성된 웹 애플리케이션에서 작동합니다.
Cucumber는 FIT가 수행하는 것과 유사한 표에서보다 간결한 테스트를 지원합니다.
Cucumber는 요구 사항, 자동화 된 테스트 및 문서를 일관된 것으로 결합하여 소프트웨어 개발 수명주기를 혁신했습니다. 즉, 소프트웨어를 검증하는 일반 텍스트 실행 가능 사양입니다.

SpecFlow

SpecFlow는 .NET 플랫폼 용 BDD 도구입니다. SpecFlow는 오픈 소스 프로젝트입니다. 소스 코드는 GitHub에서 호스팅됩니다.

SpecFlow는 기능에 Gherkin 구문을 사용합니다. Gherkin 형식은 Cucumber에서 도입했으며 다른 도구에서도 사용됩니다. Gherkin 언어는 GitHub의 프로젝트로 유지됩니다.https://github.com/cucumber/gherkin

굴다

Behave는 Python 프레임 워크에 사용됩니다.

Behave는 "features"라는 디렉토리에 저장된 세 가지 유형의 파일로 작동합니다.
- 동작 시나리오가 포함 된 기능 파일.
- 시나리오에 대한 Python 단계 구현이있는 "steps"디렉토리
- 선택적으로 일부 환경 제어 (단계, 시나리오, 기능 또는 전체 촬영 경기 전후에 실행할 코드).
Behave 기능은 Gherkin (일부 수정 포함)을 사용하여 작성되며 "name.feature"라는 이름이 지정됩니다.
기능 및 시나리오에 연결된 태그는 전달 된 "기능"또는 "시나리오"개체를 통해 환경 기능에서 사용할 수 있습니다. 이러한 개체에는 기능 파일에서 찾은 순서대로 첨부 된 태그 이름 목록 인 "태그"라는 속성이 있습니다.
작은 오이 표준에 대한 수정-
- Behave는 표준 Gherkin 파일을 구문 분석하고 Gherkin을 확장하여 소문자 단계 키워드를 허용 할 수 있습니다.

상추

Lettuce는 Cucumber를 기반으로 한 매우 간단한 BDD 도구입니다. Python 프로젝트에 대한 자동화 된 테스트로 일반 텍스트 기능 설명을 실행할 수 있습니다. Lettuce는 BDD에서 가장 일반적인 작업을 목표로합니다.

콩 코디 언

Concordion은 Java Framework 용 Example by Example을 자동화하기위한 오픈 소스 도구입니다.

핵심 기능은 간단하지만 강력한 확장 프레임 워크 API를 사용하면 Excel 스프레드 시트를 사양으로 사용하고, 스크린 샷을 출력에 추가하고, 로깅 정보를 표시하는 등의 기능을 추가 할 수 있습니다.

Concordion을 사용하면 단락, 표 및 적절한 구두점을 사용하여 일반 언어로 사양을 작성할 수 있으며 Given / When / Then을 사용하는 구조화 된 언어는 필요하지 않습니다.

Concordion은 다음을 포함한 다른 언어로 이식되었습니다.

C # (Concordion.NET)
Python (PyConcordion)
루비 (Ruby-Concordion)

Cucumber는 실행 파일 사양, 테스트 자동화 및 생활 문서를 지원하는 도구입니다.

행동 기반 개발은 예제 별 사양으로 확장됩니다. 또한 테스트 주도 개발 모범 사례, 특히 외부에서 작업하는 관점을 공식화합니다. 개발 작업은 실행 가능한 사양을 기반으로합니다.

그만큼 key features 실행 가능한 사양은 다음과 같습니다-

실행 가능한 사양은-
- 시스템의 동작을 나타내는 예제에서 파생되었습니다.
- 비즈니스 및 이해 관계자를 포함하여 개발에 관련된 모든 사람의 협력으로 작성되었습니다.
- 수락 기준을 기반으로합니다.
실행 가능한 사양을 기반으로하는 수락 테스트가 자동화됩니다.
공유 된 유비쿼터스 언어는 실행 가능한 사양과 자동화 된 테스트를 작성하는 데 사용됩니다.
- 도메인 별 용어는 개발 과정에서 사용됩니다.
- 고객과 이해 관계자를 포함한 모든 사람이 동일한 방식으로 시스템, 요구 사항 및 구현에 대해 이야기합니다.
- 요구 사항, 설계 문서, 코드, 테스트 등에있는 시스템을 설명하는 데 동일한 용어가 사용됩니다.
- 누구나 요구 사항과 더 많은 요구 사항을 생성하는 방법을 읽고 이해할 수 있습니다.
- 변경 사항을 쉽게 수용 할 수 있습니다.
- 라이브 문서가 유지됩니다.

Cucumber는 실행 가능한 사양을 시스템의 실제 코드 및 자동화 된 승인 테스트와 함께 연결하므로이 프로세스에 도움이됩니다.

이 작업을 수행하는 방식은 실제로 고객과 개발자가 함께 작업하도록 설계되었습니다. 승인 테스트를 통과하면 그것이 나타내는 시스템 동작의 사양이 올바르게 구현되었음을 의미합니다.

전형적인 오이 수용 테스트

다음 예를 고려하십시오.

Feature − Sign up

가입은 빠르고 친절해야합니다.
시나리오-성공적인 가입
- New 사용자는 확인 이메일을 받고 개인적으로 인사를 받아야합니다.
- Given 가입하기로 선택했습니다.
- When 유효한 세부 정보로 등록합니다.
- Then 확인 이메일을 받아야합니다.
- And 맞춤 인사말 메시지가 표시되어야합니다.

이 예에서 볼 수 있습니다.

합격 테스트는 Features.
기능은 다음과 같이 설명됩니다. Scenarios.
시나리오는 다음으로 구성됩니다. Steps.

사양은 일반 텍스트 파일의 자연 언어로 작성되지만 실행 가능합니다.

오이의 작용

Cucumber는 시스템에 대해 실행할 수있는 시나리오를 찾는 기능이 포함 된 텍스트 파일을 처리하는 명령 줄 도구입니다. 오이가 어떻게 작동하는지 이해합시다.

쉽게 시작할 수 있도록 파일 이름과 파일 위치 (각 폴더)에 대한 많은 규칙을 사용합니다.
Cucumber를 사용하면 사양, 자동화 된 테스트 및 문서를 같은 장소에 보관할 수 있습니다.
각 시나리오는 시나리오의 사전 조건, 조치 및 사후 조건을 설명하는 단계 목록입니다. 각 단계가 오류없이 실행되면 시나리오는 통과 된 것으로 표시됩니다.
실행이 끝나면 Cucumber는 통과 한 시나리오 수를보고합니다.
실패한 경우 개발자가 진행할 수 있도록 실패한 내용에 대한 정보를 제공합니다.

오이에서, Features, Scenarios, 단계는 다음과 같은 언어로 작성됩니다. Gherkin.

Gherkin은 구조가있는 일반 텍스트 영어 (또는 60 개 이상의 다른 언어 중 하나)입니다. Gherkin은 배우기 쉽고 구조를 통해 간결한 방식으로 예제를 작성할 수 있습니다.

Cucumber는 Gherkin으로 작성된 실행 가능 사양이 포함 된 파일을 실행합니다.
Cucumber는 일반 텍스트 Gherkin Steps를 시스템과 상호 작용할 작업으로 변환하기 위해 Step Definitions가 필요합니다.
Cucumber는 시나리오에서 단계를 실행할 때 실행할 일치하는 단계 정의를 찾습니다.
단계 정의는 패턴이 첨부 된 작은 코드 조각입니다.
이 패턴은 단계 정의를 일치하는 모든 단계에 연결하는 데 사용되며 코드는 오이가 작은 오이 단계를 볼 때 Cucumber가 실행하는 것입니다.
각 단계는 단계 정의와 함께 제공됩니다.
대부분의 단계는 입력을 수집 한 다음 프레임 워크를 호출하기 위해 애플리케이션 도메인에 특정한 프레임 워크에 위임합니다.

Cucumber는 12 개 이상의 다양한 소프트웨어 플랫폼을 지원합니다. 자신에게 맞는 Cucumber 구현을 선택할 수 있습니다. 모든 Cucumber 구현은 동일한 전체 기능을 제공하며 자체 설치 절차와 플랫폼 별 기능도 있습니다.

매핑 단계 및 단계 정의

Cucumber의 핵심은 단계와 단계 정의 간의 매핑입니다.

오이 구현

다음은 Cucumber 구현입니다.

	Ruby / JRuby
	JRuby (Cucumber-JVM 사용)
	자바
	그루비
	.NET (SpecFlow 사용)
	자바 스크립트
	JavaScript (Cucumber-JVM 및 Rhino 사용)
	클로저
	고수
	루아
	PHP (Behat 사용)
	자이 썬
	C ++
	Tcl

프레임 워크 통합

다음은 프레임 워크 구현입니다.

	Ruby on Rails
	셀렌
	PicoContainer
	스프링 프레임 워크
	Watir

작은 오이는 글쓰기에 사용되는 언어입니다. Features, Scenarios, and Steps. Gherkin의 목적은 구체적인 요구 사항을 작성하도록 돕는 것입니다.

구체적인 요구 사항이 의미하는 바를 이해하려면 다음 예를 고려하십시오.

고객은 유효하지 않은 신용 카드 정보를 입력하지 않도록해야합니다.

대

고객이 정확히 16 자리가 아닌 신용 카드 번호를 입력 한 경우 양식을 제출하려고 할 때 올바른 자릿수를 알려주는 오류 메시지와 함께 다시 표시되어야합니다.

후자는 모호함이없고 오류를 방지하며 훨씬 더 테스트 가능합니다.

Gherkin은보다 구체적인 요구 사항을 생성하도록 설계되었습니다. Gherkin에서 위의 예는 다음과 같습니다.

Feature

유효하지 않은 신용 카드 정보 입력시 피드백 Feature Definition

사용자 테스트에서, 우리는 실수 있도록 많은 사람들이 본 문서

Background True for all Scenarios Below

Given 구매할 항목을 선택했습니다.

And 신용 카드 번호를 입력하려고합니다.

Scenario − 신용 카드 번호가 너무 짧습니다.Scenario Definition

When 16 자리 미만의 카드 번호를 입력했습니다.

And 다른 모든 세부 사항이 정확합니다.

And 나는 양식을 제출Steps

Then 양식이 다시 표시되어야합니다

And 올바른 자릿수를 알려주는 메시지가 표시되어야합니다.

Gherkin 형식 및 구문

Gherkin 파일은 일반 텍스트 파일이며 확장자는 .feature입니다. 비어 있지 않은 각 줄은 Gherkin 키워드로 시작해야하며 그 뒤에 원하는 텍스트가 있어야합니다. 키워드는-

Feature
Scenario
주어진, 언제, 그때, 그리고, 그러나 (단계)
Background
시나리오 개요
Examples
"" "(문서 문자열)
| (데이터 테이블)
@ (태그)
# (코멘트)
*

특색

그만큼 Feature키워드는 소프트웨어 기능을 설명하고 관련 시나리오를 그룹화하는 데 사용됩니다. 기능에는 세 가지 기본 요소가 있습니다.

키워드 – 기능.
Feature 키워드와 같은 줄에 제공되는 기능의 이름입니다.
여러 줄에 걸쳐있을 수있는 선택적 (하지만 강력하게 권장되는) 설명, 즉 키워드 Feature를 포함하는 줄과 시나리오, 배경 또는 시나리오 개요로 시작하는 줄 사이의 모든 텍스트.

이름과 설명 외에도 기능에는 시나리오 또는 시나리오 개요 목록과 선택적 배경이 포함됩니다.

이름을 지정하는 것이 일반적입니다. .feature지형지 물의 이름을 가져 와서 소문자로 변환하고 공백을 밑줄로 대체하여 파일. 예를 들면

feedback_when_entering_invalid_credit_card_details.feature

시스템에서 기능을 식별하기 위해 "기능 주입 템플릿"을 사용할 수 있습니다.

<사용자 유형>으로서 <목표를 달성하기 위해> <특징>을 원합니다

설명

Gherkin 문서의 일부는 키워드로 시작할 필요가 없습니다.

기능, 시나리오, 시나리오 개요 또는 예제 다음의 줄에서 키워드로 시작하는 줄이없는 한 원하는 것을 작성할 수 있습니다. 설명을 포함하는 방법입니다.

대본

시스템의 동작을 표현하기 위해 각 기능에 하나 이상의 시나리오를 첨부합니다. 기능에 대한 모든 동작을 완전히 지정하기 위해 기능 당 5-20 개의 시나리오를 보는 것이 일반적입니다.

시나리오는 다음 패턴을 따릅니다.

초기 컨텍스트 설명
이벤트 설명
예상되는 결과 설명

컨텍스트에서 시작하여 작업을 설명하고 결과를 확인합니다. 이것은 단계로 수행됩니다. Gherkin은 각 컨텍스트, 작업 및 결과를 단계로 설명하는 세 가지 키워드를 제공합니다.

Given − 컨텍스트 설정
When − 조치 수행
Then − 결과 확인

이러한 키워드는 시나리오의 가독성을 제공합니다.

Example

Scenario − 계좌에서 돈을 인출합니다.

Given 내 계정에 $ 100가 있습니다.
When 20 달러를 요청합니다.
Then $ 20가 분배되어야합니다.

여러 개있는 경우 Given 또는 When 서로 아래 단계를 사용할 수 있습니다. And 또는 But. 시나리오를 자세히 지정할 수 있습니다.

Example

Scenario − 도난당한 카드로 출금을 시도합니다.

Given 내 계정에 $ 100가 있습니다.
But 내 카드가 유효하지 않습니다.
When 50 달러를 요청합니다.
Then 내 카드는 반환되지 않아야합니다.
And 은행에 연락하라고해야합니다.

시나리오를 만드는 동안 '각 시나리오는 의미가 있어야하며 다른 시나리오와 독립적으로 실행할 수 있어야합니다. 이것은-

한 시나리오의 성공 조건은 이전에 다른 시나리오가 실행되었다는 사실에 따라 달라질 수 없습니다.
각 시나리오는 특정 컨텍스트를 만들고 한 가지를 실행하고 결과를 테스트합니다.

이러한 시나리오는 다음과 같은 이점을 제공합니다.

테스트는 더 간단하고 이해하기 쉽습니다.
시나리오의 하위 집합 만 실행할 수 있으며 테스트 집합의 중단에 대해 걱정할 필요가 없습니다.
시스템에 따라 테스트를 병렬로 실행하여 모든 테스트를 실행하는 데 걸리는 시간을 줄일 수 있습니다.

시나리오 개요

여러 입력 또는 출력이있는 시나리오를 작성해야하는 경우 값만 다른 여러 시나리오를 작성하게 될 수 있습니다. 해결책은 시나리오 개요를 사용하는 것입니다. 시나리오 개요를 작성하려면

시나리오 개요 단계의 변수는 <및>로 표시됩니다.
변수에 대한 다양한 값은 표에 예제로 제공됩니다.

Example

계산기에 두 개의 숫자를 더하는 기능을 작성한다고 가정 해 보겠습니다.

Feature − 추가.

Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input    | output |
| 2+2      | 4      | 
| 98+1     | 99     |
| 255+390  | 645    |

시나리오 개요 섹션 다음에는 항상 테이블의 컨테이너 인 하나 이상의 예제 섹션이 나옵니다. 테이블에는 시나리오 개요 단계의 변수에 해당하는 헤더 행이 있어야합니다. 아래의 각 행은 변수 값을 채우는 새 시나리오를 만듭니다.

SpecFlow는 오픈 소스 프로젝트입니다. 소스 코드는 GitHub에서 호스팅됩니다. SpecFlow에서 애플리케이션의 기능 (사용 사례, 사용자 스토리)에 대한 승인 기준을 저장하는 데 사용하는 기능 파일은 Gherkin 구문을 사용하여 정의됩니다.

Gherkin 형식은 Cucumber에서 도입했으며 다른 도구에서도 사용됩니다. Gherkin 언어는 GitHub의 프로젝트로 유지됩니다.https://github.com/cucumber/gherkin

기능 요소 및 SpecFlow

기능 요소의 주요 기능은-

기능 요소는 기능 파일에 대한 헤더를 제공합니다. 기능 요소에는 애플리케이션의 해당 기능에 대한 이름과 고급 설명이 포함됩니다.
- SpecFlow는 기능 이름에서 파생 된 클래스 이름으로 기능 요소에 대한 단위 테스트 클래스를 생성합니다.
- SpecFlow는 수용 기준을 나타내는 시나리오에서 실행 가능한 단위 테스트를 생성합니다.
기능 파일에는 기능의 승인 테스트를 설명하는 데 사용되는 여러 시나리오가 포함될 수 있습니다.
- 시나리오에는 이름이 있으며 여러 시나리오 단계로 구성 될 수 있습니다.
- SpecFlow는 시나리오 이름에서 파생 된 메서드 이름을 사용하여 각 시나리오에 대한 단위 테스트 메서드를 생성합니다.

여러 시나리오 단계

시나리오에는 여러 시나리오 단계가있을 수 있습니다. 수락 테스트를 구성하는 사전 조건, 작업 또는 확인 단계를 정의하는 세 가지 유형의 단계가 있습니다.

다른 유형의 단계는 Given, When 또는 Then 키워드 각각 및 동일한 유형의 후속 단계는 And 과 But 키워드.
Gherkin 구문은 이러한 세 가지 유형의 단계 조합을 허용하지만 일반적으로 시나리오에는 Given, When 과 Then 진술.
시나리오 단계는 텍스트를 사용하여 정의되며 DataTable이라는 추가 테이블 또는 DocString 인수라는 여러 줄 텍스트를 가질 수 있습니다.
시나리오 단계는 애플리케이션을 자동화하기 위해 사용자 지정 코드를 실행하는 기본 방법입니다.
SpecFlow는 각 시나리오 단계에 대해 단위 테스트 메서드 내에서 호출을 생성합니다. 이 호출은 시나리오 단계와 일치하는 단계 정의를 실행하는 SpecFlow 런타임에 의해 수행됩니다.
일치는 런타임에 수행되므로 바인딩이 아직 구현되지 않은 경우에도 생성 된 테스트를 컴파일하고 실행할 수 있습니다.
시나리오 단계에 테이블과 여러 줄 인수를 포함 할 수 있습니다. 이는 단계 정의에서 사용되며 추가 테이블 또는 문자열 인수로 전달됩니다.

시나리오 개요

시나리오 개요를 사용하여 데이터 기반 수락 테스트를 정의 할 수 있습니다. 시나리오 개요는 항상 시나리오 템플릿 사양 (<placeholder> 구문을 사용하는 데이터 자리 표시자가있는 시나리오) 및 자리 표시 자에 대한 값을 제공하는 일련의 예제로 구성됩니다.

단위 테스트 프레임 워크에서 지원하는 경우 SpecFlow는 시나리오 개요에서 행 기반 테스트를 생성합니다.
그렇지 않으면 시나리오 개요에 대한 매개 변수화 된 단위 테스트 논리 방법과 각 예제 집합에 대한 개별 단위 테스트 방법을 생성합니다.
더 나은 추적 성을 위해 생성 된 단위 테스트 메서드 이름은 시나리오 개요 제목과 예제의 첫 번째 값 (예제 표의 첫 번째 열)에서 파생됩니다.
따라서 예제 세트의 첫 번째 열로 고유하고 설명적인 매개 변수를 선택하는 것이 좋습니다.
Gherkin 구문에서는 모든 예제 열에 시나리오 개요에서 일치하는 자리 표시자가 있어야하므로 테스트 이름을 더 쉽게 읽을 수있는 데 사용되는 예제 집합에 임의의 열을 도입 할 수도 있습니다.
SpecFlow는 단계 바인딩을 일치시키기 전에 별도의 단계로 자리 표시 자 대체를 수행합니다.
따라서 단계 바인딩의 구현 및 매개 변수는 직접 시나리오 또는 시나리오 개요를 통해 실행되는지 여부와 무관합니다.
이를 통해 나중에 단계 바인딩을 변경하지 않고 승인 테스트에서 추가 예제를 지정할 수 있습니다.