행위 주도 개발

행위 주도 개발(Behavior-driven development, BDD)은 코드의 행위를 설명하기 위해 도메인 언어를 사용하여 소프트웨어 테스트 이름을 지정하는 것을 포함한다.

BDD는 행위와 예상 결과를 표현할 수 있는 자연어 구문(예: 영어와 유사한 문장)을 사용하는 도메인 특화 언어(DSL)를 활용한다.

지지자들은 이것이 소프트웨어 프로젝트에서 개발자, 품질 보증 전문가 및 고객 담당자 간의 협력을 장려한다고 주장한다. 이는 팀이 대화와 구체적인 예시를 사용하여 애플리케이션이 어떻게 작동해야 하는지에 대한 공유된 이해를 공식화하도록 장려한다. BDD는 문제 공간이 복잡할 때 특히 효과적인 관행으로 간주된다.

BDD는 테스트 주도 개발(TDD)의 개선된 형태로 간주된다. BDD는 TDD 기술과 도메인 주도 설계 및 객체 지향 분석 및 설계의 아이디어를 결합하여 소프트웨어 개발 및 관리 팀에 소프트웨어 개발 협력을 위한 공유 도구와 공유 프로세스를 제공한다.

상위 수준에서 BDD는 비즈니스 이해관계와 기술적 통찰력을 모두 사용하여 소프트웨어 개발을 관리해야 하는 방법에 대한 아이디어다. 그 실천은 전문 도구의 사용을 포함한다. BDD를 위한 일부 도구는 TDD에도 사용할 수 있다. 이 도구들은 유비쿼터스 언어를 자동화한다.

 개요 

BDD는 DSL 구조화된 자연어 문장을 실행 가능한 테스트로 변환하는 프로세스이다. 그 결과는 주어진 기능에 대한 인수 기준처럼 읽히는 테스트이다.

따라서 BDD는 TDD의 확장이다.

BDD는 다음 사항에 중점을 둔다.

 프로세스 어디서부터 시작할지
 무엇을 테스트하고 무엇을 테스트하지 않을지
 한 번에 얼마나 테스트할지
 테스트 이름을 무엇으로 지을지
 테스트가 실패하는 이유를 어떻게 이해할지

본질적으로 BDD는 자연스럽게 발생하는 문제를 피하기 위해 자동화된 테스트(유닛 테스트 및 인수 검사 포함)에 대한 접근 방식을 다시 생각하는 것이다. 예를 들어, BDD는 유닛 테스트 이름이 조건부 동사(예: 영어에서 "should")로 시작하는 완전한 문장이어야 하며, 비즈니스 가치 순서로 작성되어야 한다고 제안한다. 인수 테스트는 표준 애자일 프레임워크인 유저 스토리를 사용하여 작성되어야 한다: "[역할/행위자/이해관계자]로서 [기능/역량]을 원하며 [이점]을 얻는다". 인수 기준은 시나리오 관점에서 작성되어야 하며 클래스로 구현되어야 한다: 주어진 [초기 컨텍스트], [이벤트 발생 시], [결과 확인] .

이 지점에서 출발하여 많은 사람들이 수년간 BDD 프레임워크를 개발했으며, 마침내 소프트웨어 프로젝트의 개발자, QA 및 비기술 또는 비즈니스 참가자를 위한 의사소통 및 협업 프레임워크로 정의했다.

 원칙 

BDD는 소프트웨어 테스트가 원하는 동작의 관점에서 명명되어야 한다고 제안한다. 애자일 소프트웨어 개발에서 차용한 "원하는 동작"은 이 경우 비즈니스에 의해 설정된 요구사항, 즉 구축 중인 소프트웨어 단위에 대해 의뢰한 주체에게 비즈니스 가치를 제공하는 원하는 동작을 의미한다. BDD 실천 내에서 이는 BDD가 "외부에서 안으로" 활동하는 것으로 언급된다.

TDD는 높은 수준의 소프트웨어 요구사항, 낮은 수준의 기술적 세부사항 또는 그 중간의 어떤 것도 테스트의 관점에서 구별하지 않는다. 따라서 BDD를 보는 한 가지 방법은 TDD의 진화로서 더 구체적인 선택을 한다는 것이다.

 행동 사양 

또 다른 BDD 제안은 원하는 동작을 지정하는 방법과 관련된다. BDD는 객체 지향 분석 및 설계 분야의 유저 스토리 사양에서 차용한 행동 사양을 위한 준공식적인 형식을 사용하는 것을 제안한다. 이 형식의 시나리오 측면은 도메인 특화 언어를 사용하여 소프트웨어의 행동 사양에 호어 논리를 적용하는 것으로 간주될 수 있다.

BDD는 비즈니스 분석가와 소프트웨어 개발자가 이 분야에서 협력해야 하며, 각 유저 스토리가 명시적으로 문서화된 유저 스토리 관점에서 동작을 지정해야 한다고 제안한다. 각 유저 스토리는 어느 정도 다음 구조를 따라야 한다:

 제목 명시적인 제목.

 내러티브 다음 구조를 가진 짧은 서론 섹션:
 ~로서: 기능의 혜택을 받을 사람 또는 역할;
 ~하고 싶다: 기능;
 ~를 위해: 기능의 혜택 또는 가치.

 인수 기준 다음 구조를 가진 내러티브의 각 특정 시나리오에 대한 설명:
주어진: 시나리오 시작 시의 초기 컨텍스트, 하나 이상의 절로 구성;
때: 시나리오를 트리거하는 이벤트;
그러면: 예상되는 결과, 하나 이상의 절로 구성.

BDD는 이 정보가 어떻게 형식화되어야 하는지를 요구하지 않지만, 팀이 위의 요소를 포함하는 상대적으로 간단하고 표준화된 형식을 결정해야 한다고 제안한다. 또한 시나리오는 상호 작용이 일어나는 UI 요소에 대한 언급 없이 비즈니스 언어로 선언적으로 표현되어야 하며, 명령적으로 표현되어서는 안 된다고 제안한다. 이 형식은 큐컴버에서 거킨 언어로 지칭된다.

 유비쿼터스 언어로서의 명세 

BDD는 도메인 주도 설계에서 유비쿼터스 언어의 개념을 차용한다. 유비쿼터스 언어는 소프트웨어 개발자 및 비기술 인력을 포함한 소프트웨어 개발 팀의 모든 구성원이 공유하는 (반)공식 언어이다. 해당 언어는 모든 팀 구성원이 해당 소프트웨어의 도메인을 논의하는 공통 수단으로 사용하고 개발한다. 이런 식으로 BDD는 소프트웨어 프로젝트의 모든 다른 역할 간의 의사소통 수단이 된다.

소프트웨어 개발의 일반적인 위험에는 개발자와 비즈니스 이해관계자 간의 의사소통 단절이 포함된다. BDD는 원하는 행동의 사양을 프로젝트 팀 구성원을 위한 유비쿼터스 언어로 사용한다. 이것이 BDD가 행동 사양에 대해 준공식 언어를 주장하는 이유이다. 즉, 일부 형식성은 유비쿼터스 언어가 되기 위한 요구사항이다. 또한, 이러한 유비쿼터스 언어를 갖는 것은 사양의 도메인 모델을 생성하여 사양을 공식적으로 추론할 수 있도록 한다. 이 모델은 또한 사용 가능한 다양한 BDD 지원 소프트웨어 도구의 기반이 된다.

위에 제시된 예시는 개발 중인 소프트웨어 시스템에 대한 유저 스토리를 설정한다. 이 유저 스토리는 이해관계자, 비즈니스 효과 및 비즈니스 가치를 식별한다. 또한 전제 조건, 트리거 및 예상 결과를 포함하는 여러 시나리오를 설명한다. 이러한 각 부분은 언어의 보다 공식적인 부분(예: 주어진이라는 용어는 키워드로 간주될 수 있음)에 의해 정확히 식별되며, 따라서 유비쿼터스 언어의 공식적인 부분을 이해하는 도구에 의해 어떤 식으로든 처리될 수 있다.

대부분의 BDD 애플리케이션은 텍스트 기반 DSL 및 사양 접근 방식을 사용한다. 그러나 통합 시나리오의 그래픽 모델링 또한 실제로 성공적으로 적용되었는데, 예를 들어 테스트 목적을 위해 사용되었다.

 특수 도구 

TDD와 마찬가지로 BDD는 특수 도구를 사용하는 것을 포함할 수 있다.

BDD는 TDD와 같이 테스트 코드가 필요할 뿐만 아니라, 더 사람이 읽기 쉬운 언어로 동작을 설명하는 문서도 필요하다. 이를 위해서는 테스트 실행, 설명 읽기 및 구문 분석, 테스트 코드 읽기 및 실행할 해당 테스트 구현 찾기의 두 단계 프로세스가 필요하다. 이 프로세스는 BDD를 개발자에게 더 번거롭게 만든다. 지지자들은 BDD 문서가 사람이 읽을 수 있는 특성 때문에 상대적으로 비기술적인 청중에게도 가치가 있으며, 따라서 요구사항("기능")을 설명하는 의사소통 수단으로 사용될 수 있다고 제안한다.

 도구 원칙 

원칙적으로 BDD 지원 도구는 TDD를 지원하는 도구와 마찬가지로 소프트웨어 테스트 프레임워크이다. 그러나 TDD 도구가 테스트 지정에 허용되는 형식에 상당히 자유로운 반면, BDD 도구는 유비쿼터스 언어의 정의와 연결되어 있다.

유비쿼터스 언어는 비즈니스 분석가가 개발자도 이해할 수 있는 방식으로 행동 요구 사항을 문서화할 수 있도록 한다. BDD 지원 도구의 원칙은 이러한 요구 사항 문서를 직접 실행 가능한 테스트 컬렉션으로 만드는 것이다. 사양 실행을 가능하게 하는 기술 도구와 관련된 이유로 이를 달성할 수 없는 경우, 행동 요구 사항을 작성하는 스타일을 변경하거나 도구를 변경해야 한다. 행동 요구 사항의 정확한 구현은 도구마다 다르지만, 애자일 실천은 다음과 같은 일반적인 프로세스를 제시했다.

 도구가 사양 문서를 읽는다.
 도구는 유비쿼터스 언어의 완전한 형식 부분을 직접 이해한다(위 예시의 Given 키워드와 같은). 이를 기반으로 도구는 각 시나리오를 의미 있는 절로 나눈다.
 시나리오의 각 개별 절은 유저 스토리에 대한 테스트를 위한 일종의 매개변수로 변환된다. 이 부분은 소프트웨어 개발자의 프로젝트별 작업을 필요로 한다.
 프레임워크는 해당 시나리오의 매개변수를 사용하여 각 시나리오에 대한 테스트를 실행한다.

 스토리와 사양 
행위 주도 개발의 별도 하위 범주는 사용자 스토리 대신 사양을 입력 언어로 사용하는 도구에 의해 형성된다. 사양 도구는 테스트 시나리오의 입력 형식으로 사용자 스토리를 사용하지 않고 테스트 중인 단위의 기능 사양을 사용한다. 이러한 사양은 종종 사용자 스토리보다 더 기술적인 특성을 가지며 일반적으로 비즈니스 담당자와의 의사소통에 덜 편리하다. 스택에 대한 사양의 예시는 다음과 같다.

 사양: 스택

 새로운 스택이 생성될 때
 비어 있다

 스택에 요소가 추가될 때
 그 요소는 스택의 맨 위에 있다

 스택에 N개의 요소가 있고
 요소 E가 스택 맨 위에 있을 때
 팝 연산은 E를 반환한다
 스택의 새로운 크기는 N-1이다

이러한 사양은 테스트 중인 구성 요소의 동작을 정확하게 지정할 수 있지만, 비즈니스 사용자에게는 덜 의미가 있다. 결과적으로, BDD 실천에서 사양 기반 테스트는 스토리 기반 테스트의 보완으로 간주되며 더 낮은 수준에서 작동한다. 사양 테스트는 종종 자유 형식 유닛 테스트의 대체품으로 여겨진다.

 세 명의 친구 

'세 명의 친구'는 '사양 워크숍'이라고도 불리며, 제품 책임자가 QA 및 개발팀과 같은 다양한 이해관계자들과 사례를 통해 요구사항을 논의하는 회의를 의미한다. 이 논의의 핵심 목표는 대화를 촉발하고 누락된 사양을 식별하는 것이다. 또한 이 논의는 QA, 개발팀 및 제품 책임자가 각자의 관점을 수렴하고 경청하여 요구사항을 풍부하게 하고 올바른 제품을 만들고 있는지 확인하는 플랫폼을 제공한다.

세 명의 친구는 다음과 같다:
 비즈니스 - 비즈니스 사용자의 역할은 문제를 정의하는 것이며 해결책을 제시하는 데 관여하지 않는다.
 개발 - 개발자의 역할은 문제를 해결할 방법을 제안하는 것을 포함한다.
 테스트 - 테스터의 역할은 해결책에 의문을 제기하고, '만약 ~라면' 시나리오를 통해 가능한 많은 다른 가능성을 제시하여 브레인스토밍을 하고, 해결책을 더 정확하게 만들어 문제를 해결하는 데 도움을 주는 것이다.

 같이 보기 
 사례 기반 명세
 비햇 (PHP 프레임워크)
 사이네핀 프레임워크
 콩코르디언 (자바 프레임워크)
 RSpec
 게이지 (소프트웨어)
 재스민 (자바스크립트 테스트 프레임워크)
 스퀴시 GUI 테스터 (JavaScript, Python, Perl, Ruby 및 Tcl용 BDD GUI 테스트 도구)
 유스 케이스
 핏네스는 BDD를 출시하는 데 사용되었다.

 각주 

분류:소프트웨어 테스트
분류:소프트웨어 개발 철학
분류:소프트웨어 설계