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

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는 배달 팀과 도메인 전문가 간의 안정적인 의사 소통 기반을 기반으로 그러한 다리를 구축하는 데 도움이됩니다.

더 알아보기

If you want to read more about BDD, I wrote a book on the subject. “Writing Great Specifications” explores the art of analyzing requirements and will help you learn how to build a great BDD process and use examples as a core part of that process. The book talks about the ubiquitous language, collecting examples, and creating so-called executable specifications (automated tests) out of the examples—techniques that help BDD teams deliver great softeware on time and on budget.

If you are interested in buying “Writing Great Specifications,” you can save 39% with the promo code 39nicieja2 :)

---

I have experimented a little with the BDD approach and my premature conclusion is that BDD is well suited to use case implementation, but not on the underlying details. TDD still rock on that level.

BDD is also used as a communication tool. The goal is to write executable specifications which can be understood by the domain experts.

---

It seems to me that BDD is a broader scope. It almost implies TDD is used, that BDD is the encompasing methodology that gathers the information and requirements for using, amongh other things, TDD practices to ensure rapid feedback.

---

With my latest knowledge in BDD when compared to TDD, BDD focuses on specifying what will happen next, whereas TDD focuses on setting up a set of conditions and then looking at the output.

---

Behaviour Driven Development seems to focus more on the interaction and communication between Developers and also between Developers and testers.

The Wikipedia Article has an explanation:

Behavior-driven development

Not practicing BDD myself though.

---

Consider the primary benefit of TDD to be design. It should be called Test Driven Design. BDD is a subset of TDD, call it Behavior Driven Design.

Now consider a popular implementation of TDD - Unit Testing. The Units in Unit Testing are typically one bit of logic that is the smallest unit of work you can make.

When you put those Units together in a functional way to describe the desired Behavior to the machines, you need to understand the Behavior you are describing to the machine. Behavior Driven Design focuses on verifying the implementers' understanding of the Use Cases/Requirements/Whatever and verifies the implementation of each feature. BDD and TDD in general serves the important purpose of informing design and the second purpose of verifying the correctness of the implementation especially when it changes. BDD done right involves biz and dev (and qa), whereas Unit Testing (possibly incorrectly viewed as TDD rather than one type of TDD) is typically done in the dev silo.

I would add that BDD tests serve as living requirements.

---

BDD is largely TDD done right. However, there's additional value that BDD offers. Here's a link on that:

BDD is more than “TDD done right”

---

Difference between test-driven development (TDD) and behavior-driven development (BDD)

• BDD focuses on the behavioural aspect of the system rather than the
  implementation aspect of the system that TDD focuses on.

• BDD gives a clearer understanding as to what the system should do
  from the perspective of the developer and the customer. TDD only
  gives the developer an understanding of what the system should do.

• BDD allows both the developer and the customer to work together to on requirements analysis that is contained within the source code of the system.

---

In short there is major difference between TDD and BDD In TDD we are majorly focused on Test data In BDD our main focus is on behavior of the project so that any non - programming person can understand the line of code on the behalf of the title of that method

---

Here's the quick snapshot:

• TDD is just the process of testing code before writing it!

• DDD is the process of being informed about the Domain before each cycle of touching code!

• BDD is an implementation of TDD which brings in some aspects of DDD!

---

There is no difference betwen TDD and BDD. except you can read your tests better, and you can use them as requirements. If you write your requirements with the same words as you write BDD tests then you can come frome your client with some of your tests defined ready to write code.

참고URL : https://stackoverflow.com/questions/2509/what-are-the-primary-differences-between-tdd-and-bdd