TDD와 BDD의 주요 차이점은 무엇입니까? [닫은]

테스트 주도 개발은 지난 몇 년 동안 .NET 커뮤니티에서 가장 큰 인기를 끌었습니다. 최근에 ALT.NET 커뮤니티에서 BDD에 대한 불평을 들었습니다. 무엇입니까? TDD와 다른 점은 무엇입니까?

BDD 는 테스트 보다 사양 에 관한 것임을 이해합니다 합니다. 그것은 도메인 주도 디자인에 연결되어 있습니다 (이 * DD 약어를 좋아하지 않습니까?).

높은 수준의 테스트를 포함하여 사용자 스토리를 작성하는 특정 방법과 연결됩니다. Tom ten Thij 의 예 :

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

(Tom의 기사에서 Tom은이 테스트 사양을 Ruby로 직접 실행합니다.)

BDD의 교황은 Dan North 입니다. BDD 소개 기사 에서 훌륭한 소개를 찾을 수 있습니다.

이 비디오 에서 BDD와 TDD의 비교를 찾을 수 있습니다. 또한 Jeremy D. Miller의 "TDD done right"라는 BDD에 대한 의견

2013 년 3 월 25 일 업데이트

위의 동영상이 잠시 동안 누락되었습니다. 다음은 Llewellyn Falco의 최근 BDD vs TDD (설명) 입니다. 나는 그의 설명이 명확하고 요점을 발견했다.

나에게 BDD와 TDD의 주요 차이점은 초점과 표현입니다. 그리고 말은 당신의 의도를 알리는 데 중요합니다.

TDD는 테스트에 중점을 둡니다. "오래된 폭포 세계"에서 테스트가 구현 된 이후에이 사고 방식은 잘못된 이해와 행동으로 이어집니다.

BDD는 행동과 사양에 중점을 두므로 폭포 정신이 산만 해집니다. 따라서 BDD는 테스트 방식이 아니라 설계 방식으로보다 쉽게 ​​이해됩니다.

BDD에는 두 가지 유형이 있습니다.

첫 번째는 Dan North가 논의한 원래 스타일이며 xBehave 스타일 프레임 워크를 생성했습니다. 나에게이 스타일은 주로 도메인 개체에 대한 승인 테스트 또는 사양에 적용 할 수 있습니다.

두 번째 스타일은 Dave Astels가 대중화 한 스타일이며, 나에게는 새로운 이점 인 TDD의 새로운 형식입니다. 테스트보다는 행동과 소규모 테스트 클래스에 중점을 두어 기본적으로 스펙 (테스트) 방법 당 한 줄을 갖도록 노력합니다. 이 스타일은 모든 수준의 테스트에 적합하며 기존 단위 테스트 프레임 워크를 사용하여 수행 할 수 있지만 최신 프레임 워크 (xSpec 스타일)는 테스트가 아닌 동작에 중점을 둡니다.

유용한 BDD 그룹도 있습니다.

http://groups.google.com/group/behaviordrivendevelopment/

테스트 주도 개발 은 테스트 우선 소프트웨어 개발 방법론으로, 테스트 할 실제 코드를 작성하기 전에 테스트 코드를 작성해야합니다. 켄트 벡의 말에서 :

여기서 스타일은 몇 줄의 코드를 작성한 다음 실행하지 않을 테스트를 작성하는 테스트 또는 실행하는 테스트를 작성하고 실행되는 코드를 작성하는 것입니다.

하나의 작은 코드 조각을 작성하는 방법을 알아 낸 후, 이제는 그냥 코딩하는 대신 즉각적인 피드백을 받고 "약간 코딩하고, 약간 테스트하고, 약간 코드를 작성하고, 조금 테스트하십시오." 그래서 우리는 즉시 테스트를 작성합니다.

따라서 TDD는 프로그래머가 작동하는 깨끗한 코드를 생성하는 데 사용하는 저수준의 기술 방법론입니다.

행동 주도 개발 은 TDD를 기반으로 만들어졌지만 프로그래머와 테스터에게만 해당되는 것이 아니라 전체 팀과 모든 중요 이해 관계자 (기술적 및 비 기술적)를 다루는 프로세스로 발전한 방법론입니다. BDD는 TDD가 잘 대답하지 못하는 몇 가지 간단한 질문으로 시작했습니다. 얼마나 많은 테스트를 작성해야합니까? 실제로 무엇을 테스트해야합니까? 내가 작성하는 테스트 중 어느 것이 비즈니스 나 제품의 전반적인 품질에 실제로 중요할까요?

보시다시피 이러한 질문에는 기술과 비즈니스 간의 협력이 필요합니다. 비즈니스 이해 관계자와 도메인 전문가는 종종 엔지니어에게 유용한 테스트가 어떤 종류인지 테스트 할 수 있지만 테스트가 중요한 비즈니스 측면을 다루는 고급 테스트 인 경우에만 가능합니다. BDD는“이 기능이 올바르게 작동하는 방법에 대한 예를 알려주십시오”와 같이 비즈니스와 유사한 테스트를“예”라고하며 데이터 유효성 검사 또는 API 통합 테스트와 같은 저수준 기술 검사를 위해“test”라는 단어를 예약합니다. 중요한 부분은 테스트 는 프로그래머와 테스터 만 만들 수 있지만 디자이너, 분석가 등 전체 배달 팀이 예제 를 수집하고 분석 할 수 있다는 것입니다.

한 문장에서, 지금까지 내가 찾은 BDD의 가장 좋은 정의 중 하나는 BDD가“도메인 전문가와 대화하고 원하는 행동을 이해하고 미지의 것을 발견하기 위해 예를 사용하는 것”에 관한 것입니다. 발견 부분은 매우 중요합니다. 배달 팀이 더 많은 예제를 수집할수록 비즈니스 영역을 점점 더 이해하기 시작하므로 처리해야하는 제품의 일부 측면에 대한 불확실성이 줄어 듭니다. 불확실성이 감소함에 따라 전달 팀의 창의성과 자율성이 증가합니다. 예를 들어, 이제 기술 전문 지식이 부족하여 비즈니스 사용자가 불가능하다고 생각한 사례를 제안 할 수 있습니다.

이제 비즈니스 및 도메인 전문가와 대화하는 것이 좋지만 실제로는 그 결과가 얼마나 자주 발생하는지 알고 있습니다. 나는 프로그래머로서 기술로 여행을 시작했다. 프로그래머로서 우리는 알고리즘, 디자인 패턴, 추상화와 같은 코드 를 작성 하도록 배웁니다 . 또는 디자이너 인 경우 디자인— 정보를 구성하고 아름다운 인터페이스를 만듭니다. 그러나 우리가 엔트리 레벨의 일자리를 얻었을 때 고용주는 "고객에게 가치를 제공 할 것"을 기대합니다. 그리고 그 고객들 중에는 은행이 될 수 있습니다. 그러나 계좌 잔고를 효율적으로 줄이는 방법을 제외하고는 은행에 대해 아무것도 알 수 없었습니다. 그래서 나는 어떻게 든 내 코드를 어떻게 든 변환해야 할 것입니다 ... 나는 가치를 제공하려면 은행과 기술 전문 지식 사이의 다리를 만들어야합니다. BDD는 배달 팀과 도메인 전문가 간의 안정적인 의사 소통 기반을 기반으로 그러한 다리를 구축하는 데 도움이됩니다.

더 알아보기

BDD에 대해 더 자세히 알고 싶다면 주제에 관한 책을 썼습니다. “훌륭한 사양 작성” 에서는 요구 사항 분석 기술을 살펴보고 훌륭한 BDD 프로세스를 구축하는 방법을 배우고 해당 프로세스의 핵심 부분으로 예제를 사용하는 데 도움을줍니다. 이 책은 유비쿼터스 언어, 예제 수집 및 BDD 팀이 시간과 예산에 따라 훌륭한 소프트웨어를 제공하는 데 도움이되는 기술을 통해 실행 가능한 사양 (자동 테스트)을 생성하는 것에 대해 설명합니다.

“Writing Great Specification”을 구매 하고 싶다면 프로모션 코드 39nicieja2로 39 % 를 절약 할 수 있습니다. :)

BDD 접근 방식에 대해 약간 실험했으며 BDD가 사례 구현에 적합하지만 기본 세부 사항에는 적합하지 않다는 결론을 내 렸습니다. TDD는 여전히 그 수준에서 흔들리고 있습니다.

BDD는 통신 도구로도 사용됩니다. 목표는 도메인 전문가가 이해할 수있는 실행 가능한 사양을 작성하는 것입니다.

BDD가 더 넓은 범위 인 것 같습니다. 그것은 TDD가 사용되었음을 암시하며, BDD는 빠른 피드백을 보장하기 위해 TDD 사례를 사용하기위한 정보와 요구 사항을 수집하는 포괄적 인 방법론이라는 것을 의미합니다.

TDD와 비교할 때 BDD에 대한 최신 지식을 바탕으로 BDD는 다음에 일어날 일을 지정하는 데 중점을 두는 반면, TDD는 조건 세트를 설정하고 출력을 보는 데 중점을 둡니다.

행동 주도 개발은 개발자와 개발자와 테스터 간의 상호 작용 및 커뮤니케이션에 더 중점을 둔 것으로 보입니다.

Wikipedia 기사에 설명이 있습니다.

행동 중심 개발

그래도 BDD를 연습하지는 않습니다.

TDD의 주요 이점은 디자인이라고 생각하십시오. 테스트 구동 설계라고합니다. BDD는 TDD의 하위 집합입니다.이를 행동 중심 설계라고합니다.

이제 널리 사용되는 TDD-단위 테스트 구현을 고려하십시오. 단위 테스트의 단위는 일반적으로 가장 작은 작업 단위 인 하나의 논리입니다.

기계에 대해 원하는 동작을 설명하기 위해 해당 장치를 기능적인 방식으로 조합 할 때 기계에 설명하는 동작을 이해해야합니다. Behavior Driven Design은 사용 사례 / 요구 사항 / 무엇에 대한 구현 자의 이해를 확인하고 각 기능의 구현을 검증하는 데 중점을 둡니다. BDD와 TDD는 일반적으로 디자인을 알리는 중요한 목적과 특히 구현이 변경 될 때 구현의 정확성을 확인하는 두 번째 목적을 제공합니다. BDD는 biz 및 dev (및 qa)와 관련이 있으며, 단위 테스팅 (한 유형의 TDD가 아닌 TDD로 잘못 간주 될 수 있음)은 일반적으로 dev 사일로에서 수행됩니다.

BDD 테스트는 생활 요건으로 제공됩니다.

BDD는 대부분 TDD가 올바르게 수행됩니다. 그러나 BDD가 제공하는 부가 가치가 있습니다. 이에 대한 링크는 다음과 같습니다.

BDD는“TDD가 올바르게 완료되었습니다”

TDD와 BDD 사이에는 차이가 없습니다. 테스트를 더 잘 읽을 수 있고 요구 사항으로 사용할 수 있다는 점만 다릅니다. BDD 테스트를 작성할 때와 같은 단어로 요구 사항을 작성하는 경우 코드를 작성할 준비가 된 테스트 중 일부를 클라이언트에서 가져올 수 있습니다.

테스트 중심 개발 (TDD)과 행동 중심 개발 (BDD)의 차이점

• BDD는
  TDD가 중점을 둔 시스템 의 구현 측면 보다는 시스템의 행동 측면에 중점을 둡니다.

• BDD는
  개발자와 고객의 관점에서 시스템이 무엇을해야하는지에 대한 명확한 이해를 제공합니다 . TDD
  는 개발자에게 시스템이 수행해야하는 작업에 대한 이해 만 제공합니다.

• BDD를 사용하면 개발자와 고객 모두가 시스템의 소스 코드 내에 포함 된 요구 사항 분석을 위해 협력 할 수 있습니다.

간단히 말해서 TDD와 BDD 사이에는 큰 차이가 있습니다. TDD에서 우리는 주로 테스트 데이터에 중점을 둡니다. BDD에서 우리의 주요 초점은 프로젝트의 행동에 중점을 두므로 프로그래밍을하지 않은 사람은 누구나 그 방법

빠른 스냅 샷은 다음과 같습니다.

• TDD는 코드를 작성하기 전에 테스트하는 과정입니다!

• DDD는 각 터치 코드주기 전에 도메인에 대해 알리는 프로세스입니다!

• BDD는 DDD의 일부 측면을 가져 오는 TDD의 구현입니다!