[Test Code] TDD와 BDD와 ATDD에 대해서

TDD(Test Driven Development)

• 테스트 주도 개발
• 기능 중점

BDD(Behavioral Driven Development)

• 행동 주도 개발
• 시스템 동작 중점

ATDD(Acceptance Test Driven Development)

• 인수 테스트 주도 개발
• 요구사항 중점

 

[TDD란?]

개발자의 관점에서 구현된 테스트 방법론이다.

모든 작은 기능에 대한 테스트 사례를 설계하고 작성을 하는 것이다.

주요 의도는 테스트 실패 시에만 새로운 코드를 수정하거나 작성하는 것이다.

따라서 테스트 스크립트 중복이 줄고 애자일 개발 생태계에서 널리 사용되고 있다.
TDD 접근 방식에서 자동화된 테스트 스크립트는 코드의 기능적인 부분보다 먼저 작성된다.

 

TDD 단계

1. 문서에 지정된 요구사항을 기반으로 개발자는 테스트 케이스를 작성한다.
2. 실제 기능이 개발되기 전에 테스트 코드가 작성되고 실행되면서 테스트가 실패하는 경우도 있다.
   테스트 코드가 패스될 수 있도록 실제 코드를 작성하고 수정한다.
3. 중복 코드 제거, 일반화 등의 리팩토링을 한다.
   (리팩토링 👉 주요 기능이나 동작을 변경하지 않고 코드를 수정하는 포로세스)

장점

재작업에 필요한 시간을 단축한다.

오류에 대해 빠른 탐색에 도움을 준다.

더 빠른 피드백을 받을 수 있도록 도움을 준다.

클린코드와 더 나은 디자인의 개발을 장려한다.

생산성이 향상되고 협업이 장려된다.

유연하고 유지관리가 쉬운 광범위한 코드가 생성된다.

 

 

[BDD란?]

TDD에서 파생된 테스트 접근 방식으로 주로 시스템 동작을 기반으로 작성되며 개발자와 비계발자의 협업 과정을 녹여낸 방법이다.
TDD는 매번 개발을 진행하면서 기능에 대해 예외사항에 대해 생각하고 테스트 케이스를 작성하는 것은 많은 비용이든다.

BDD는 동작을 기반으로 기능을 개발하는 다양한 방법을 정의해 주며 이미 작성된 요구사항이나 기획서에 맞추어 테스트 케이스를 작성하게 된다면 TDD와 같은 시간에 대한 비용이 줄어들게 된다.

시나리오를 기반으로 테스트를 작성하며 함수 단위 테스트를 권장하지 않고 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 레벨을 권장한다.

위 그림처럼 TDD는 상황에 따라 설계를 다시 하면서 기존 코드 수정이 커지는 리스크가 있는 반면에 BDD는 재설계시 코드 작성 전이라 비용 리스크가 적다는 것을 알 수 있다.

 

BDD 단계

Feature : 테스트에 대상의 기능/책임을 명시한다.

Scenario : 테스트 목적에 대한 상황을 설명한다.

Given : 시나리오 진행에 필요한 값을 설정한다.

When : 시나리오를 진행하는데 필요한 조건을 명시한다.

Then : 시나리오를 완료했을 때 보장해야 하는 결과를 명시한다.

e.g.) (given) 사용자가 유효한 로그인 자격 증명을 입력 (when) 로그인 버튼 클릭 (then) 성공적인 유효성 검사 메시지 표시

이처럼 모든 사람들이 기능 동작을 이해할 수 있도록 작성되어야 한다.

 

BDD Cycle

 

장점

각 모듈의 역할이 단순해지고 명확해진다.

프로젝트의 유지보수와 확장이 쉽다.

수동 테스트에서 시간을 단축할 수 있다.

놓칠 수 있는 것들을 반복 테스트 하기에 좋다.

프로젝트의 품질을 높이고, 효율적인 테스트 경험과 사용자의 입장을 고려한 개발을 진행할 수 있도록 해준다.

실제 사용자의 실행 환경과 거의 동일한 환경에서 테스트를 진행하기 때문에 실제 상황에서 발생할 수 있는 에러를 사전에 발견 할 수 있다.

 

 

[ATDD 란?]

요구사항에 대한 인수 테스트를 이용하여 요구사항을 명확히 하고 모든 팀원이 요구사항에 대해 공통의 이해를 바탕으로 개발을 진행하는 방법을 말한다.

주로 시스템의 기능적 동작을 만족시키는데 중점을 두고 있다.

 

BDD와의 차이점은?

BDD는 ATDD보다 기능 동작의 중점을 두고 있다면 ATDD는 정확한 요구사항을 수행하는데 더 중점을 두고 있다.

 

인수 조건 정의

인수 테스타가 충족해야하는 조건을 말하며 시나리오 기반의 표현 방식을 사용한다.(e.g. given / when / then)

인수 조건을 작성하는 벙법으로는

• 검증하고자 하는 when구문을 먼저 작성한다.
• 기대 결과를 의미하는 then 구문을 작성한다.
• when과 then에 필요한 정보를 given에 작성한다.

 

ATDD의 장점

요구사항의 모호함 없이 명확한 분석이 가능하다

다른 포지션의 관점은 물론 업무 프로세스도 간접적으로 익힐 수 있다.

다른 포지션의 진행 상황에 대한 인지와 이해도가 높아진다.

 

 

[TDD와 BDD와 ATDD의 주요 차이점]

	TDD	BDD	ATDD
정의	기능 구현에 더 중점을 둔 개발 기술	시스템의 동작에 초점을 맞춘 개발 기술	요구 사항을 정의하는데 더 중점을 둔 기술
참여자	개발자	개발자, 고객, QA 등	개발자, 고객, QA 등
사용언어	기능 개발에 사용되는 것과 유사한 언어로 작성됨 (e.g. Java, Python 등)	간단한 영어	간단한 영어
주요 초점	단위 테스트	요구 사항 이해	인수 테스트 작성

 

 

 

Reference.
https://mingule.tistory.com/43
bdd-behaviour-driven-development에-대한-간략한-정리
https://data-make.tistory.com/724
https://www.browserstack.com/guide/tdd-vs-bdd-vs-atdd