TDD, BDD

Introduction

테스트는 개발자가 일을 마치고 산출물을 만들었을 때 1+1(n)같이 따라붙는 덤 같은 존재입니다.
간혹 시간이 부족하거나 피치못할 사정으로 테스트가 생략되는 경우가 있습니다.
운이 좋아 아무런 문제가 없는 경우도 있겠지만, 대부분의 경우 생각치 못한 경우에서 결함이 발생하는 경우를 경험해보셨을 거라 짐작합니다.

테스트는 정말 중요합니다. 그리고 테스트는 연구하는 사람에게 있어 '일' 입니다.
테스트가 빠진 개발물은 완료된 작업이 아님을 명심해야 합니다.

여기서는 이렇게 중요한 테스트에 대해서 더 자세히 알고 어떤 방법을 통해 개발에 적용이 가능한지와 이를 넘어서 테스트 주도 개발 방법론을 개발에 적용하는 이야기하고자 합니다.

테스트의 정의

시스템이나 시스템의 구성 요소 또는 SW 프로그램을 실행하고 평가하는 과정으로, IEEE(Institute of Electrical and Electronics Engineers) 정의에 따르면 수작업 또는 자동화된 방법으로 규정된 요구사항을 만족시키고 있는지 검증하고, 
기대되는 결과와 실제 결과의 차이를 식별하는 작업을 말한다. G.J Myers의 정의에 따르면 일반적으로 결함이 없음을 증명하는 것이 아니라 결함이 있음을 발견하기 위하여 체계적으로 수행하는 일련의 작업을 통칭한다.

TDD, BDD

테스트의 목적

다양한 목적의 테스트가 있을 수 있으나, 기본적인 것은 아래와 같다.

• 품질 수준에 대한 자신감의 획득과 정보의 제공
• 비즈니스 리스크를 감소시키는 정보에 근거한 결과 제공
• 개발 프로세스 점검 및 이슈 제기
• 논리적 설계의 구현의 검증
• 시스템과 SW가 명세를 충족하는지 확인

발췌) http://www.oss.kr/oss_repository6/64881

TDD (Test-Driven Development)

테스트 주도 개발(Test-driven development TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 
우선 개발자는 바라는 향상 또는 새로운 함수를 정의하는 (초기적 결함을 점검하는) 자동화된 테스트 케이스를 작성한다. 
그런 후에, 그 케이스를 통과하기 위한 최소한의 양의 코드를 생성한다. 
그리고 마지막으로 그 새 코드를 표준에 맞도록 리팩토링한다. 
이 기법을 개발했거나 '재발견' 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어준다고 말하였다.

참조) https://ko.wikipedia.org/wiki/%ED%85%8C%EC%8A%A4%ED%8A%B8_%EC%A3%BC%EB%8F%84_%EA%B0%9C%EB%B0%9C

BDD (Behaviour-Driven Development)

Behavior-Driven Development은 TDD를 근간으로 파생된 프로그래밍 개발 프로세스이다. 
TDD에서 한발 더 나아가 테스트 케이스 자체가 요구사양이 되도록 하는 개발 방식이다. 
TDD에서는 유닛 테스트로 작성된 테스트 코드의 가독성을 높이고 테스트 케이스에 대한 문서를 작성해왔는데, 
BDD는 이것을 결합테스트와 시나리오 테스트까지 확장하여 각각에 해당하는 문서들을 대체했다. 
어디서부터 테스트를 시작할지, 어떤 것을 테스트하고 어떤 것은 하지 않을지, 한 번에 얼마만큼을 테스트할지, 
테스트에 어떤 이름을 붙일지 그리고 테스트가 왜 실패했는지 등에 대한 고민을 BDD를 통해 해결할 수가 있게 된 것이다. 
테스트 메소드의 이름을 “이 클래스가 어떤 행위를 해야한다. (should do something)”라는 식의 문장으로 작성하여 행위를 위한 테스트에 집중을 하게 하는 것이다. 

발췌) http://asfirstalways.tistory.com/296