BDD와 TDD의 관계

BDD와 TDD의 관계는 무엇입니까?

내가 이해 한 바에 따르면, BDD는 TDD에 대한 두 가지 주요 요소 인 테스트 명명 (확보 / 수정)과 승인 테스트를 추가합니다. BDD가 개발하는 동안 TDD를 따라야합니까? 그렇다면, 내 TDD 단위 테스트의 이름이 동일한 보장 / 스타일이어야합니까?

BDD는 TDD주기 주위에주기를 추가합니다.

따라서 동작부터 시작하여 테스트를 진행 한 다음 테스트가 개발을 주도하게하십시오. 이상적으로 BDD는 일종의 합격 테스트에 의해 주도되지만 100 % 필요하지는 않습니다. 예상되는 동작이 정의되어 있으면 괜찮습니다.

로그인 페이지를 작성한다고 가정 해 봅시다.

행복한 길로 시작하십시오.

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

이 Given-And-When-And-Then-And 구문은 동작 중심 개발에서 일반적입니다. 그것의 장점 중 하나는 개발자가 아닌 사람이 읽고 읽을 수 있다는 것입니다. 즉, 이해 관계자는 작업을 성공적으로 완료하기 위해 정의한 동작 목록을보고 확인할 수 있다는 것입니다. 불완전한 제품을 출시하기 오래 전에 그들의 기대와 일치합니다.

Gherkin이라고하는 스크립팅 언어가 있는데, 위와 매우 비슷하며 이러한 동작의 절 뒤에 테스트 코드를 작성할 수 있습니다. 일반적인 개발 프레임 워크에 Gherkin 기반 번역기를 찾아야합니다. 그것은이 답변의 범위를 벗어났습니다.

어쨌든, 행동으로 돌아갑니다. 현재 응용 프로그램은 아직이 작업을 수행하지 않고 (그렇다면 변경을 요청하는 이유는 무엇입니까?) 테스트 러너를 사용하거나 단순히 수동으로 테스트하든이 테스트에 실패합니다.

이제 TDD 주기로 전환하여 해당 기능을 제공 할 차례입니다.

BDD 작성 여부에 관계없이 테스트 이름은 공통 구문으로 지정해야합니다. 가장 일반적인 것 중 하나는 설명해야 할 "should"구문입니다.

테스트 작성 : ShouldAcceptValidDetails. 만족할 때까지 Red-Green-Refactor주기를 진행하십시오. 이제 행동 테스트를 통과합니까? 그렇지 않은 경우, 다른 테스트를 작성해야합니다 : ShouldRedirectToUserDefaultPage. 당신이 행복 할 때까지 빨강 녹색 리 팩터. 행동에 명시된 기준을 충족 할 때까지 씻고 헹구고 반복하십시오.

그리고 우리는 다음 행동으로 넘어갑니다.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

이제 이전 행동을 통과시키기 위해 이것을 선점해서는 안됩니다. 이 시점에서이 테스트에 실패해야합니다. TDD 사이클로 다시 내려가십시오.

그리고 페이지가 생길 때까지 계속하십시오.

Ruby 개발자가 아닌 경우에도 BDD 및 TDD에 대한 자세한 내용은 Rspec Book 을 강력히 권장 합니다.

그것에 대한 나의 이해 :

• BDD는 행동에 초점을 맞추기 위해 TDD의 브랜드 변경으로 시작했습니다.
• 동작 및 실행 스펙에 초점을 맞추기 위해보다 공식적인 지원 (DSL 및 툴링)을 제공합니다.
• BDD는 이제 TDD의 상위 집합으로 볼 수 있습니다. 시간이 지남에 따라 더 많은 요구 사항 도출 측면을 포괄하지만 개발 프로세스 측면이 핵심 요소입니다.

따라서 BDD의 올바른 부분을 수행하는 TDD를 처리합니다. BDD는 프로세스의 의도를 명확하게하기 위해 TDD의 언어 변경으로 시작되었습니다. BDD에 관한 Dan North의 입문 기사 는 테스트보다는 단어 행동에 초점을 맞추는 것이 유용한 이유를 설명합니다. 소프트웨어를 올바르게 구축하는 것이 아니라 올바른 소프트웨어를 구축하고 있음을 확인하는 데 도움이됩니다. 이것은 항상 좋은 TDD 접근 방식의 일부 였지만 Dan은이 방법을 BDD에 약간 코드화했습니다.

내가 생각하는 것은 BDD가 TDD보다 조금 더 명시 적으로 또는 최소한 공식화하고 도구를 지원하는 것입니다.이 2 사이클 / 이중 루프 / 줌 인 축소 / 외부 인 접근 방식입니다. 먼저 기능의 예상 동작 (외부 루프)을 설명한 다음 내부 루프를 확대하여 저수준 사양을 처리합니다.

에서 http://www.metesreau.com/ncraft-workshop/

Gurkin은 Cucumber 및 SpecFlow와 같은 도구와 함께 이러한 고급 기능 사양을 작성한 다음 응용 프로그램 코드를 실행하는 코드에 연결하는 방법을 제공합니다. 나는 이것이 BDD가 TDD와 다른 느낌을 가질 수있는 곳이라고 주장하지만, 도구 지원과 DSL이 추가 되어도 여전히 똑같은 일을하고 있습니다. '전통적인'TDD에 더 가까운 것은 rspec, nspec, spock과 같은 도구를 사용하는 것입니다. 이것들은 당신이 '전통적인'TDD에서하는 것과 같은 과정과 조금 더 비슷하지만 더 행동 중심의 언어로 느낍니다.

에서 액션 BDD (추천) 존 퍼거슨 스마트로, 그 다음 낮은 수준의 사양 스팍 같은 도구로 떨어지고, 외부 수준 실행 사양에서 JBehave를 같은 것을 시작으로, 이중 루프 방식에 대한 옹호.

BDD는 테스트 중심 개념을 비즈니스 이해 관계자에게 더 가깝게 만듭니다. Gherkin은 비즈니스가 읽을 수 있도록 설계되었으며 '살아있는 문서'라는 아이디어, 즉 실행 가능한 사양에서 자동으로 생성 된 진행률 보고서는 이해 관계자에게 피드백을 제공하는 것입니다.

현재 BDD의 또 다른 부분은 더 큰 프로세스의 일부로 TDD를 통합하는 무언가가되는 곳입니다. 요구 사항 추출 비트 및 조각입니다. 기능 주입, 영향 매핑 및 실제 옵션과 같은 아이디어가이 측면의 일부입니다.

이에 대한 정식 답변을 위해서는 Dan North로 다시가는 것이 가장 좋습니다 . 팀이 모두 개발자 인 경우 BDD = TDD입니다. 팀에 광범위한 이해 관계자가 참여하는 경우 BDD는 XP에 더 가깝고 TDD는 그 일부입니다.

BDD와 TDD의 관계는 무엇입니까?

그들은 같은 것입니다.

내가 이해 한 바에 따르면 BDD는 TDD보다 두 가지 주요 사항을 추가합니다.

그것은 실제로 BDD가 "추가"하는 것이 아닙니다. TDD를 더 쉽게 가르치고 이해할 수 있도록하는 다른 규칙 일뿐입니다.

BDD를 만든 사람들은 모두 TDD를 가르치고 있었고 가장 이해하기 어려운 것은 TDD가 테스트와 전혀 관련이 없다는 것을 알았습니다. 학생들이 그 장애물을 극복하면 훨씬 쉬워졌습니다. 그러나 "test"라는 단어 (또는 "assert"와 같은 관련 용어)가 실제로 어디에나 나타날 때 테스트 에 대해 생각하는 것과 이혼 하기는 매우 어렵 습니다 . 그래서 그들은 몇 마디를 바꿨습니다.

그러나 그것은 단지 단어입니다! TDD와 BDD 사이 에는 실제 차이 가 없습니다 .

합격 시험.

합격 시험은 BDD와 마찬가지로 TDD의 중요한 부분입니다. 다시 : TDD와 BDD의 차이점은 없습니다. TDD 완료 는 BDD이고 BDD 는 TDD가 올바르게 완료된 것입니다.