행동 주도형 개발

Behavior-driven development
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

소프트웨어 엔지니어링에서 동작 중심 개발(BDD)은 소프트웨어 [1][2][3]프로젝트에서 개발자, 품질 보증 테스터 및 고객 담당자 간의 협업을 촉진하는 신속한 변화를 위한 소프트웨어 개발 프로세스입니다.팀에게 대화와 구체적인 예를 사용하여 응용 프로그램의 [4]동작 방법에 대한 공통 이해를 공식화할 것을 권장합니다.테스트 주도 개발(TDD)[1][2][5][6][vague][7]에서 벗어났습니다.행동 중심 개발은 TDD의 일반적인 기술과 원리를 도메인 중심 설계, 객체 지향 분석 및 설계에서 얻은 아이디어와 결합하여 소프트웨어 개발 및 관리 팀에 공유 도구와 소프트웨어 [2][7]개발에 대한 공동 프로세스를 제공합니다.

BDD는 주로 비즈니스 이익과 기술적 통찰에 의해 소프트웨어 개발이 어떻게 관리되어야 하는지에 대한 아이디어이지만, BDD의 관행은 개발 [5]프로세스를 지원하기 위해 전문 소프트웨어 도구를 사용하는 것을 전제로 하고 있습니다.이러한 툴은 BDD 프로젝트에서 사용하기 위해 특별히 개발되는 경우가 많지만 테스트 주도형 개발을 지원하는 툴의 특수한 형태로 볼 수 있습니다.툴은 BDD의 중심 테마인 유비쿼터스 언어에 자동화를 추가하는 역할을 합니다.

BDD는 행동과 예상 결과를 표현할 수 있는 자연 언어 구성체(예: 영어 문장)를 사용하는 단순 도메인 고유 언어(DSL)의 사용을 통해 주로 촉진된다.테스트 스크립트는 다양한 수준의 정교함을 갖춘 DSL에서 오랫동안 널리 사용되어 왔습니다.BDD는 특히 해결해야 할 비즈니스 문제의 "문제 공간"이 [8]복잡할 때 효과적인 기술 관행으로 간주됩니다.

역사

동작 중심 개발은 단순한 DSL을 사용하는 개발 프로세스인 테스트 중심 [9]개발의 확장입니다.이러한 DSL은 구조화된 자연어 문장을 실행 가능한 테스트로 변환합니다.그 결과, 특정 기능에 대한 허용 기준과 그 기능을 검증하는 데 사용되는 테스트와의 관계가 보다 밀접하게 됩니다.따라서 이는 일반적으로 TDD 테스트의 자연스러운 확장이다.

BDD의 주목점:

  • 프로세스의 시작점
  • 테스트 대상과 테스트 대상 외
  • 한 번에 테스트하는 양
  • 테스트의 명칭
  • 테스트 실패 이유 이해 방법

BDD의 핵심은 유닛 테스트와 수용 테스트에 대한 접근방식을 재고하여 자연스럽게 발생하는 문제를 회피하는 것입니다.예를 들어, BDD는 단위 테스트 이름은 조건 동사("예를 들어 영어로 "해야 한다")로 시작하는 전체 문장이며 비즈니스 가치의 순서로 작성되어야 한다고 제안합니다.수용 테스트는 사용자 사례의 표준 민첩 프레임워크를 사용하여 작성해야 한다. "[역할/배우/스테크홀더가 되는 것] 나는 [특징/능력]을 산출하는 것을 원한다."합격 기준은 시나리오의 관점에서 작성되어야 하며 클래스에서 구현되어야 한다.[초기 컨텍스트]를 지정하면 [이벤트]가 발생했을 때 [일부 결과 확인]을 클릭합니다.

이 시점부터 많은 사람들이 BDD 프레임워크를 수년간 개발하여 최종적으로 개발자, QA 및 소프트웨어 프로젝트의 [10]비기술자 또는 비즈니스 참여자를 위한 커뮤니케이션 및 협업 프레임워크의 관점에서 BDD 프레임워크를 구축했습니다.2009년 11월 런던에서 열린 "Agile 사양, BDD 및 Testing eXchange"에서[11] Dan North는 BDD에 대해 다음과 같이 설명했습니다.

BDD는 2세대 외부 인, 풀 기반, 다중 이해관계자, 다단계, 고자동화, 신속한 변화를 위한 방법론입니다.명확한 출력과의 상호 작용 사이클을 설명하고, 결과적으로 중요한 테스트 완료 소프트웨어를 제공합니다.

2013년 GOTO Conference에서 Dan North와의 인터뷰에서 Liz Keogh는[12] BDD를 다음과 같이 정의했습니다.

예를 들어 어플리케이션의 동작을 설명하고 있습니다.그리고 그 예들에 대해 대화를 나누는 것.[13]

Dan North는 BDD 프레임워크인 JBehave를 만든 후 RBehave라고 불리는[14] 루비용 스토리 레벨의 BDD 프레임워크를 만들어 나중에 RSpec [15]프로젝트에 통합했습니다.또한 David Chelimsky, Aslak Hellesöy 등과 함께 RSpec을 개발하고 "RSpec Book:RSPec, 오이, 그리고 친구들과의 행동 주도적 발전.RSpec의 첫 번째 층 기반 프레임워크는 나중에 주로 Aslak Hellesöy가 개발한 Ooy로 대체되었다.Ooy 테스트 프레임워크의 일부인 Capybara는 이러한 웹 기반 테스트 자동화 소프트웨어 중 하나입니다.

BDD의 원리

테스트 주도 개발은 소프트웨어 개발 방법론으로서 기본적으로 소프트웨어 개발자는 각 소프트웨어 유닛에 대해 다음을 수행해야 한다고 명시되어 있습니다.

  • 장치에 대한 테스트 세트를 먼저 정의한다.
  • 시험을 실패하게 한다.
  • 그 후 유닛을 구현한다.
  • 마지막으로 장치의 구현이 테스트를 성공시키는지 확인합니다.

이 정의는 높은 수준의 소프트웨어 요건, 낮은 수준의 기술적 세부 사항 또는 그 사이의 모든 측면에서 테스트를 허용한다는 점에서 다소 구체적이지 않습니다.따라서 BDD를 바라보는 시각 중 하나는 TDD보다 더 구체적인 선택을 하는 TDD의 지속적인 발전이라는 것이다.

동작 주도 개발에서는 소프트웨어 유닛의 테스트가 [5][7][1]유닛의 바람직한 동작에 따라 지정되도록 규정되어 있습니다.신속한 변화를 위한 소프트웨어 개발에서 차용되는 "희망 행동"은 비즈니스에 의해 설정된 요건,[5][1] 즉 구축 중인 소프트웨어 유닛에 위탁된 모든 운영 주체에게 비즈니스 가치가 있는 바람직한 동작으로 구성됩니다.BDD 프랙티스에서는, 이것을 「외부」[16]액티비티라고 부릅니다.

동작 사양

이 기본적인 선택에 이어 BDD에 의한 두 번째 선택은 원하는 동작을 지정하는 방법에 관한 것입니다.이 영역에서 BDD는 객체 지향 분석 및 설계 분야에서 사용자 스토리 사양에서 차용된 행동 사양에 세미 형식 형식을 사용하는 것을 선택한다.이 형식의 시나리오 측면은 상황의 도메인 고유의 언어를 사용하여 소프트웨어 유닛의 동작 사양에 Hoare 로직을 적용한 것으로 간주할 수 있다.

BDD는 비즈니스 분석가 및 개발자가 이 영역에서 협업해야 하며 사용자 사례의 관점에서 동작을 지정해야 한다고 명시하고 있습니다. 사용자 사례들은 각각 전용 [1][16]문서에 명시되어 있습니다.각 사용자 사례는 어떤 식으로든 다음 [5][16]구조를 따라야 합니다.

제목
명시적 제목
내러티브
다음과 같은 구조를 가진 간단한 소개 섹션:
  • A로서: 이 기능을 이용할 수 있는 사람 또는 역할
  • 갖고 싶다: 기능;
  • 즉, 기능의 장점 또는 가치입니다.
합격 기준
다음과 같은 구조를 가진 서술의 각 특정 시나리오에 대한 설명:
  • 지정: 시나리오 시작 시 첫 번째 컨텍스트(1개 또는 여러 구)
  • 시기: 시나리오를 트리거하는 이벤트
  • 그런 다음, 하나 이상의 절에서 예상되는 결과입니다.

BDD는, 이러한 유저 스토리를 적는 방법에 대해서는, 어떠한 형식적인 요구도 가지고 있지 않습니다만, BDD를 사용하는 각 팀은,[5][16] 상기의 요소를 포함한 유저 스토리를 적기 위한 심플하고 표준화된 형식을 생각해 낼 필요가 있습니다.그러나 2007년에 Dan North는 텍스트 형식의 템플릿을 제안했습니다.이 템플릿은 다양한 BDD 소프트웨어 [16]툴에서 널리 사용되고 있습니다.이 포맷의 간단한 예는 다음과 같습니다.

제목 : 반품 및 교환은 인벤토리로 이동합니다.저는 가게 주인으로서 반품이나 교환 시 재고를 추적하기 위해 재고에 다시 추가하고 싶습니다.시나리오 1: 환불을 위해 반품된 아이템은 인벤토리에 추가해야 합니다.이전에 고객이 저에게서 검은색 스웨터를 구입했고, 저는 검은색 스웨터를 3개 가지고 있기 때문에, 그들이 환불을 위해 검은색 스웨터를 반품할 때, 저는 4개의 검은색 스웨터를 재고로 가지고 있을 것입니다.시나리오 2: 교환된 아이템은 인벤토리로 반환해야 합니다.고객이 이전에 저로부터 파란색 옷을 샀고, 저는 2개의 파란색 옷과 3개의 검은색 옷을 재고로 가지고 있기 때문에, 그들이 파란색 옷을 검은색 옷으로 교환할 때, 저는 3개의 파란색 옷과 2개의 검은색 옷을 재고로 가지고 있어야 합니다.

시나리오는 비즈니스 언어로 표현되는 것이 아니라 선언적으로 표현되는 것이 이상적이며, 상호 작용이 이루어지는 [17]UI 요소를 참조하지 않습니다.

이 형식은 Gherkin 언어라고 불리며 위의 예와 유사한 구문을 가지고 있습니다.그러나 Gherkin이라는 용어는 Oy, JBehave, Chantch,[18] behat 소프트웨어 [19][20][21][22]도구에 고유합니다.

유비쿼터스 언어로서의 사양

행동 중심 개발은 도메인 중심 [5][7]설계에서 유비쿼터스 언어의 개념을 차용합니다.유비쿼터스 언어는 소프트웨어 개발자와 비기술자 [23]모두에게 공유되는 (반)정식 언어입니다.문제의 언어는 [23]모든 팀원이 문제의 소프트웨어 도메인에 대해 논의하기 위한 공통적인 수단으로 사용하고 개발했습니다.이와 같이 BDD는 소프트웨어 프로젝트의 [5][24]모든 다른 역할 간의 통신 수단이 됩니다.

소프트웨어 개발의 일반적인 리스크에는 개발자와 비즈니스 이해관계자 [25]간의 커뮤니케이션 장애가 포함됩니다.BDD는 프로젝트 팀원들이 원하는 동작의 사양을 어디서나 사용할 수 있는 언어로 사용합니다.이것이 BDD가 행동 사양에 준정식 언어를 고집하는 이유입니다.어느 정도 격식은 유비쿼터스 [5]언어가 되기 위한 요건입니다.또, 그러한 유비쿼터스 언어를 가지는 것은, 사양의 도메인 모델을 작성하기 때문에,[26] 사양은 정식으로 추론할 수 있다.이 모델은 사용 가능한 다양한 BDD 지원 소프트웨어 도구의 기반이기도 합니다.

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

대부분의 BDD 애플리케이션은 텍스트 기반 DSL과 사양 접근 방식을 사용합니다.그러나 통합 시나리오의 그래픽 모델링은 테스트 목적으로도 성공적으로 적용되었습니다.[27]

특수 공구 지원

테스트 중심 설계 관행과 마찬가지로 행동 중심 개발은 프로젝트에서 특수 지원 도구를 사용하는 것으로 가정합니다.BDD는 TDD의 보다 구체적인 버전으로 볼 수 있습니다.이는 테스트 코드뿐만 아니라 동작에 대한 설명을 사람이 읽기 쉬운 언어로 제공해야 하기 때문입니다.이를 위해서는 테스트 실행, 설명 읽기 및 해석, 테스트 코드 읽기 및 실행 대상 테스트 구현을 찾기 위한 2단계 프로세스가 필요합니다.이 프로세스에서는 개발자로서 BDD를 사용하는 것이 다소 번거롭지만, 사람이 읽을 수 있는 특성으로 인해 이러한 문서의 가치는 훨씬 더 기술적인 대상자에게까지 확대되어 요구 사항(「기능」)을 설명하는 커뮤니케이션 수단으로서 기능할 수 있습니다.

툴링 원리

원칙적으로 BDD 지원 툴은 TDD를 지원하는 툴과 마찬가지로 소프트웨어의 테스트 프레임워크입니다.다만, TDD 툴이 테스트 지정에 허가되어 있는 매우 자유로운 포맷인 경우, BDD 툴은 앞에서 설명한 유비쿼터스 언어의 정의에 링크되어 있습니다.

이미 설명한 바와 같이, 유비쿼터스 언어를 통해 비즈니스 분석가는 개발자도 이해할 수 있는 방식으로 행동 요구사항을 기록할 수 있습니다.BDD 지원 툴링의 원칙은 동일한 요구사항 문서를 테스트 모음으로 직접 실행하는 것입니다.사양의 실행을 가능하게 하는 기술 도구와 관련된 이유로 이 작업을 수행할 수 없는 경우 동작 요구 사항을 기술하는 스타일을 변경하거나 [28]도구를 변경해야 합니다.동작 요건의 정확한 실장은 툴에 따라 다르지만, 신속한 변화를 위한 실천에서는 다음과 같은 일반적인 프로세스가 제시되고 있습니다.

  • 툴이 사양 문서를 읽습니다.
  • 툴은 유비쿼터스 언어의 완전한 형식적인 부분(위 예의 주어진 키워드 등)을 직접 이해합니다.이를 바탕으로 각 시나리오를 의미 있는 절로 나눕니다.
  • 시나리오의 각 개별 절은 사용자 스토리를 테스트하기 위한 일종의 파라미터로 변환된다.이 파트에는 소프트웨어 개발자의 프로젝트별 작업이 필요합니다.
  • 그런 다음 프레임워크는 각 시나리오에 대해 해당 시나리오의 매개변수를 사용하여 테스트를 수행합니다.

Dan North는 BDD(JBehave 및 RBehave 포함)를 지원하는 다수의 프레임워크를 개발했습니다.이 프레임워크는 사용자 [5]스토리를 기록할 때 제안한 템플릿을 기반으로 작동합니다.이러한 툴은 사용 사례에 대한 텍스트 설명을 사용하며, 다른 툴(CBehave 등)도 이에 따릅니다.그러나 이 형식은 필수가 아니기 때문에 다른 형식을 사용하는 다른 도구도 있습니다.예를 들어, Fitnesse(의사결정 테이블을 중심으로 구축됨)는 [29]BDD의 롤아웃에도 사용되고 있습니다.

툴링 예시

오늘날 프로젝트에서 사용되는 BDD 소프트웨어 툴의 예는 플랫폼과 프로그래밍 언어에 따라 다릅니다.

아마도 가장 잘 알려진 것은 JBehave로, Dan North, Elizabeth Keogh, 그리고 몇몇 [30]다른 사람들에 의해 개발되었다.다음은 [20]해당 프로젝트에서 가져온 예입니다.

Game of Life의 구현을 검토합니다.도메인 전문가(또는 비즈니스 분석가)는 누군가가 게임 그리드의 시작 구성을 설정할 때 발생하는 작업을 지정할 수 있습니다.이를 위해 셀을 전환하는 사람이 수행한 여러 단계의 예를 제시하고자 할 수 있습니다.서술 부분을 건너뛰어 다음 시나리오를 일반 텍스트 문서(JBehave가 읽는 입력 문서 유형)에 작성함으로써 이 작업을 수행할 수 있습니다. 

5대 5 게임을 할 때 셀을 (3, 2)에서 전환하면 그리드는 ........................X.........................셀을 (3, 1)로 전환하면 그리드는 ....................X......X.........X....셀을 (3, 2)로 전환하면 그리드는 ................................................X......

굵은 글씨는 입력의 일부가 아닙니다.이 글자는 어떤 단어가 정식 언어로 인식되고 있는지를 나타내기 위해 여기에 포함되어 있습니다.JBehave는 Given(시나리오의 시작을 정의하는 전제 조건), When(이벤트 트리거) 및 Then(트리거에 이은 액션의 결과로 검증되어야 하는 전제 조건)이라는 용어를 인식합니다.이를 바탕으로 JBehave는 시나리오를 포함한 텍스트파일을 읽고 이를 절(set-up 절과 검증 가능한 조건이 있는 3개의 이벤트트리거)로 해석할 수 있습니다.그런 다음 JBehave는 이러한 구를 사용하여 테스트를 설정하고 이벤트 트리거에 응답하며 결과를 확인할 수 있는 코드로 전달합니다.이 코드는 프로젝트 팀의 개발자가 작성해야 합니다(JBehave가 기반으로 하는 플랫폼이기 때문에 Java).이 경우 코드는 다음과 같습니다.

사적인 게임 게임; 사적인 String Renderer 렌다라;  @기부("높이 게임으로 가로 세로 세로 세로 세로 세로 세로 세로 세로 세로 세로 세로 세로") 일반의 무효 게임 이즈 런닝(인트 폭, 인트 높이) {     게임 = 신규 게임(폭, 높이);     렌다라 = 신규 String Renderer();     게임.setObserver(렌다라); }      @ 언제("셀을 $column, $row로 전환합니다.") 일반의 무효 iToggle The Cell At(인트 기둥., 인트 배를 젓다) {     게임.토글셀(기둥., 배를 젓다); }  @그러면("그리드는 $grid와 같아야 합니다.") 일반의 무효 그리드 보기맘에 들다(스트링 격자무늬) {     라고 단언하다(렌다라.asString(), 등가(격자무늬)); }

이 코드에는 시나리오의 모든 유형의 절에 대한 메서드가 있습니다.JBehave는 주석 사용을 통해 어떤 메서드가 어떤 절에 해당하는지 식별하고 시나리오를 실행하는 동안 각 메서드를 순서대로 호출합니다.시나리오의 각 절의 텍스트는 해당 절의 코드에 지정된 템플릿텍스트와 일치해야 합니다(예를 들어 시나리오의 Given에는 "X by Y game" 형식의 절이 뒤따를 것으로 예상됩니다).JBehave는 템플릿에 대한 절의 매칭을 지원하며 템플릿에서 용어를 선택하여 테스트 코드의 메서드에 매개 변수로 전달하는 기능을 내장하고 있습니다.테스트 코드는 테스트 대상 코드와 상호 작용하여 시나리오를 기반으로 테스트를 수행하는 시나리오의 각 절 유형에 대한 구현을 제공합니다.이 경우:

  • 그theGameIsRunning메소드는 초기 게임 그리드를 설정하여 주어진 절에 반응합니다.
  • 그iToggleTheCellAtmethod는 When 절에 대해 해당 절에 설명된 토글이벤트를 기동하여 응답합니다.
  • 그theGridShouldLookLike방법은 게임 그리드의 상태를 시나리오의 예상 상태와 비교하여 Then 절에 반응합니다.

이 코드의 주요 기능은 스토리가 포함된 텍스트 파일과 테스트 중인 코드 간의 브리지입니다.테스트 코드는 테스트 대상 코드에 액세스 할 수 있는 것에 주의해 주세요(이 경우는Game)는, 매우 심플랫폼은 매우 단순합니다.테스트 코드는 간단해야 합니다.그렇지 않으면 개발자는 테스트용 테스트를 작성해야 합니다.

마지막으로 테스트를 실행하려면 JBehave는 시나리오를 포함하고 종속성을 주입하는 텍스트 파일을 식별하는 배관 코드가 필요합니다(예:Game)를 테스트 코드에 넣습니다.이 배관 코드는 JBehave의 기술 요구 사항이며 BDD 스타일의 테스트 원칙과 직접 관련이 없기 때문에 여기서는 설명하지 않습니다.

스토리 대 사양

사용자 스토리가 아닌 입력 언어로 사양을 사용하는 툴에 의해 행동 주도 개발의 개별 하위 카테고리가 형성됩니다.이 스타일의 예는 원래 Dan North에 의해 개발된 RSpec 도구입니다.사양 도구는 테스트 시나리오의 입력 형식으로 사용자 사례를 사용하는 것이 아니라 테스트 대상 장치의 기능 사양을 사용합니다.이러한 사양은, 유저 스토리보다 기술적인 성질을 가지는 경우가 많아,[5][31] 유저 스토리보다 비즈니스 담당자와의 커뮤니케이션이 용이하지 않습니다.스택 사양의 예는 다음과 같습니다.

사양:스택 새로운 스택이 생성되면 스택에 요소가 추가되면 해당 요소가 스택의 맨 위에 있음 스택에 N개의 요소가 있고 요소 E가 스택 위에 있으면 팝 조작에 의해 E가 반환되고 스택의 새 크기는 N-1이 됩니다.

이러한 사양은 테스트 대상 컴포넌트의 동작을 정확하게 지정할 수 있지만 비즈니스 사용자에게는 의미가 없습니다.그 결과, BDD 프랙티스에서는, 사양 베이스의 테스트가 스토리 베이스의 테스트의 보충으로서 인식되어 하위 레벨로 동작합니다.사양 테스트는 종종 자유 형식 [31]장치 테스트를 대체하는 것으로 간주됩니다.

RSpec 및 JDave와 같은 사양 테스트 도구는 JBehave와 같은 도구와 성격이 다릅니다.JUnit과 같은 기본 유닛 테스트 도구의 대안으로 간주되기 때문에 이러한 도구는 스토리 및 테스트 코드를 분리하지 않고 테스트 코드에 사양을 직접 삽입하는 것을 선호하는 경향이 있습니다.예를 들어 해시 테이블의 RSpec 테스트는 다음과 같습니다.[32]

묘사하라 해시 하다   허락하다(: 개요) { 해시[: 안녕하세요, '세계'] }    그것 { 기대하다(해시.신규).로. 이큐({}) }    그것 "올바른 정보를 키에 해시" 하다     기대하다(해시[: 안녕하세요]).로. 이큐('세계')   끝.    그것 '키 입력' 하다     해시.열쇠들..포함시킬까요?(: 안녕하세요).할까 있다 진실의   끝. 끝.

이 예에서는 실행 가능한 코드에 포함된 읽기 가능한 언어로 된 사양을 보여 줍니다.이 경우 도구의 선택은 다음과 같은 이름의 방법을 추가하여 사양 언어를 테스트 코드의 언어로 공식화하는 것입니다.it그리고.should또, 사양 전제 조건의 개념도 있습니다.before에, 사양의 기초가 되는 전제 조건을 나타냅니다.

테스트 결과는 다음과 같습니다.

{q} 해시에는 키에 올바른 정보가 포함되어 있어야 함

세 명의 아미고

3개의 Amigos(사양 워크숍이라고도 함)는 제품 소유자가 QA 및 개발 팀 등 다양한 이해관계자와 '사례별 사양' 형식의 요건에 대해 논의하는 회의입니다.이 논의의 주요 목표는 대화를 유도하고 누락된 사양을 식별하는 것입니다.또한 QA, 개발팀 및 제품 소유자가 서로 의견을 수렴하여 요건을 강화하고 적절한 [33]제품을 구축하고 있는지 확인할 수 있는 플랫폼도 제공됩니다.

세 명의 아미고는

  • 비즈니스 - 비즈니스 사용자의 역할은 문제를 정의하는 것(솔루션 제안에는 관여하지 않음)입니다.
  • 개발 - 문제 해결 방법을 제안하는 개발자의 역할
  • 테스트 - 테스트 담당자의 역할은 솔루션에 대해 질문하고 What-If 시나리오를 통해 브레인스토밍에 대해 다양한 가능성을 제시하여 문제를 해결하기 위한 솔루션을 보다 정확하게 만드는 것입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c d e North, Dan (March 2006). "Introducing BDD". Dan North. Retrieved 25 April 2019.
  2. ^ a b c "Behaviour-Driven Development". Archived from the original on 1 September 2015. Retrieved 12 August 2012.
  3. ^ Keogh, Liz (2009-09-07). "Introduction to Behavior-Driven Development". SkillsMatter. Retrieved 1 May 2019.
  4. ^ John Ferguson Smart (2014). BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle. Manning Publications. ISBN 9781617291654.
  5. ^ a b c d e f g h i j k Haring, Ronald (February 2011). de Ruiter, Robert (ed.). "Behavior Driven development: Beter dan Test Driven Development". Java Magazine (in Dutch). Veen Magazines (1): 14–17. ISSN 1571-6236.
  6. ^ Solis, Carlos; Wang, Xiaofeng (2011). "A Study of the Characteristics of Behaviour Driven Development". Software Engineering and Advanced Applications (SEAA), 2011 37th EUROMICRO Conference on: 383–387. doi:10.1109/SEAA.2011.76. hdl:10344/1256. ISBN 978-1-4577-1027-8. S2CID 3392536.
  7. ^ a b c d Bellware, Scott (June 2008). "Behavior-Driven Development". Code Magazine. Archived from the original on 12 July 2012. Retrieved 1 May 2019.
  8. ^ Tharayil, Ranjith (15 February 2016). "Behavior-Driven Development: Simplifying the Complex Problem Space". SolutionsIQ. Retrieved 15 February 2018.
  9. ^ Liz Keogh (June 27, 2011). "ATDD vs. BDD, and a potted history of some related stuff". Retrieved 6 May 2019.
  10. ^ "The RSpec Book – Question about Chapter 11: Writing software that matters". Archived from the original on 2009-11-07. Retrieved 2009-08-09.
  11. ^ 댄 노스:BDD를 기업에 판매하는 방법 2010-11-25 Wayback Machine에서 아카이브 완료
  12. ^ "Liz Keogh".
  13. ^ GOTO 2013 • Liz Keogh & Dan North 인터뷰 https://www.youtube.com/watch?v=g5WpUJk8He4
  14. ^ D.North, RBehave 소개
  15. ^ S.Miller, InfoQ: RSpec은 RBehave를 탑재
  16. ^ a b c d e North, Dan (11 February 2007). "What's in a Story?". Dan North. Retrieved 12 August 2012.
  17. ^ Mabey, Ben. "Imperative vs. Declarative Scenarios in user stories". Archived from the original on 3 June 2010. Retrieved 19 May 2008.
  18. ^ "nutshell — Lettuce 0.2.23 (kryptonite release) documentation". lettuce.it. Retrieved 2020-02-06.
  19. ^ "Gherkin". Retrieved 7 June 2020.
  20. ^ a b "What is JBehave?". JBehave.org. Retrieved 20 October 2015.
  21. ^ "behave is behaviour-driven development, Python style". Archived from the original on 22 January 2018. Retrieved 30 January 2018.
  22. ^ "Writing Features - Behat 3.0.12 documentation". behat documentation. Archived from the original on 19 September 2015. Retrieved 20 October 2015.
  23. ^ a b Evans, Eric (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley. ISBN 978-0-321-12521-7. Retrieved August 12, 2012.
  24. ^ North, Dan (31 May 2012). "BDD is like TDD if…". faster organisations, faster software. Dan North & Associates. Retrieved 12 August 2012.
  25. ^ Geneca (16 Mar 2011). "Why Software Projects Fail". Retrieved 16 March 2011.
  26. ^ Mahmudul Haque Azad (6 Feb 2011). "Say Hello To Behavior Driven Development". Retrieved 12 August 2012.
  27. ^ Lübke, Daniel; van Lessen, Tammo (2016). "Modeling Test Cases in BPMN for Behavior-Driven Development". IEEE Software. 33 (5): 15–21. doi:10.1109/MS.2016.117. S2CID 14539297.
  28. ^ Adam Craven (September 21, 2015). "Fundamentals of Enterprise-Scale Behaviour-Driven Development (BDD)". Retrieved 14 January 2016.
  29. ^ Ketil Jensen (December 13, 2009). "BDD with Scenario tables in Fitnesse Slim". Walk the walk. Wordpress. Retrieved 12 August 2012.
  30. ^ "jbehave.org/team-list". JBehave. 2017-05-28. Retrieved 1 May 2019.
  31. ^ a b Roy Osherove (October 4, 2008). "BDD: Behavior vs. Spec Frameworks". Retrieved 12 August 2012.
  32. ^ Jason Seifer (7 December 2011). "An Introduction To RSpec". Retrieved 27 October 2012.
  33. ^ "What are the Three Amigos in Agile?". Agile Alliance. 2016-06-16. Retrieved 2019-06-10.