TDD와 BDD

이프 카카오에서 Session 중 TDD, BDD 관련된 세션의 내용 중 TDD, BDD 내용을 정리했습니다.

TDD 와 BDD

TDD란 (Test-Driven Development)

• 테스트 주도로 개발을 진행하는 개발 방식

테스트를 작성하고 테스트를 하고 실패한 코드들을 수정한 후 다시 테스트하는것을 반복하여 진행합니다.

TDD의 장점

• Testable한 코드를 유지할 수 있다
  • Testable한 코드 : 테스트하기 쉽게 만들어진 코드, 테스트를 쉽게 하기 위해서는 테스트를 할 모듈의 역할이 명확해야하는데 이를 위해서는 모듈의 역할을 단순화해야합니다. Testable한 코드는 모듈의 크기를 줄일 수 있도록 유도하고 모듈또는 계층간 Coupling도 적게 만들어 유지보수와 확장이 가능하게 합니다.

TDD의 단점

• 지속적인 TestCase 유지보수 비용
• 일정 관리 이슈
• 귀찮음

---

BDD란 (Behaviour-Driven Development)

• TDD에서 파생
• 비지니스 요구사항에 집중하여 테스트 케이스를 작성하고 개발을 진행하는 개발 방식
• 사용자의 행위를 작성하고 결과 검증을 진행
• 함수 단위 테스트를 권장하지 않음

BDD 형식

• Given : 사용자 행위시 주어진 환경 서술
• When : 사용자 행위 서술
• Then : 행위에 따른 기대 결과 서술

예시)
Given > 
    "검수자가 Iims 로그인 상태에서"

When >
    "필요 조회조건을 미입력 후 조회"
    "필요 조회조건을 입력 후 조회"

Then >
    "조회조건을 입력하라는 경고창을 띄운다"
    "조회한 내용을 화면에 표시한다"

BDD 장점

• 기획서상 요구사항을 BDD 테스트 케이스로 모두 작성한다면 빈틈없이 서비스 설계가 가능하다.
• 불필요한 테스트 케이스 작성의 비용을 줄일 수 있다.
• 서비스의 이해가 용이하다.
• 기획 시나리오의 누락으로 재설계시 리스크를 줄일 수 있다
  • 기획서와 동기화된 테스트 케이스를 작성하며 이해가 쉬워집니다. 기획 시나리오 누락 시 설계 자체가 변경되는 경우 리스크가 큰데 이를 막기 위해서 기획의 검토가 충분해야합니다. BDD는 재설계시 테스트 케이스 작성 단계에서 기획의 빈틈을 발견할 수 있어서 리스크를 줄일 수 있습니다.

TDD와 BDD의 차이

기획서와 동기화된 테스트 케이스를 작성하며 이해가 쉬워집니다.기획 시나리오 누락 시 설계 자체가 변경되는 경우 리스크가 큽니다. 이를 막기 위해서는 기획의 검토가 충분해야합니다. BDD는 재설계시 테스트 케이스 작성 시 기획의 빈틈을 발견할 수 있어서 리스크를 줄일 수 있습니다.

 

테스트 케이스를 작성함에 있어 목적의 관점에서 차이가 있다.

• TDD 테스트 케이스는 기능을 확인이 목적
• BDD 테스트 케이스는 시나리오 주체를 기준으로 한 행위를 확인이 목적

TDD, BDD 한가지만 선택하면 되나?

• BDD와 TDD는 상호 보완적 관계
• BDD의 테스트 케이스로 시나리오 검증을 하고 해당 시나리오에서 사용되는 모듈들은 TDD로 검증해야 완벽한 테스트가 될 수 있다.

참고

https://if.kakao.com/session/106 - If(kakao)2020 - kotest가 있다면 TDD 묻고 BDD로 가!
https://cucumber.io/blog/bdd/getting-started-with-bdd-part-1 - Getting Started with BDD (Part 1)