TDD와 BDD. 그리고 DCI 패턴

[SuyeonChoi]

Testable Code

• 테스트하기 쉽게 만들어진 코드
• 테스트할 모듈의 역할이 명확해야 한다. 이를 위해서는 모듈의 역할(크기)을 단순화하는 작업이 필요하다.
• 모듈 크기를 줄이는 설계를 유도하고 모듈/계층 간의 커플링도 적게 만들기 때문에 유지보수와 확장이 가능한 코드이다

TDD와 BDD

• TDD(Test-Driven Development)

  • 테스트를 먼저 작성하고 테스트를 통과시키는 프로덕션 코드를 작성
  • 테스트 단위는 함수 단위로 작성하는 거의 모든 함수가 테스트 대상에 포함
  • 코드설계가 테스트 가능하게 작성되는 장점(Testable Code)
  • 일정관리나 리소스 관리 측면에서 부담이 크다는 단점

• BDD(Behaviour-Driven Development)

  • 테스트 대상의 상태 변화를 테스트
  • TDD에서 파생되었다. TDD에 기반을 둔다. 메서드 위주의 TDD 보다는 행동을 더 강조한다
  • 시나리오(사용자의 행위)를 기반으로 테스트 케이스를 작성
  • 설계 역시 행위의 중심이 되는 도메인 기반 설계가 가능
  • 스타일 타입
    • BehaviorSpec: Given(주어진 환경), When(행위), Then(기대 결과) 구조. 기본 패턴으로 권장
    • FeatureSpec: Feature/Scenario 구조를 지원. given, when, then을 구조화하기 전에 기능의 시나리오를 작성하게 되는데, 더 구조화하지 않고 테스트 케이스를 작성할 때 사용. 시나리오의 행위자를 정의하기 어렵거나, 기능에 대해서만 쓰여진 기획에 바로 작성할 수 있다. 대표적으로 Cucumber가 이를 지원
    • AnnotationSpec: Junit 형태의 Testcase를 작성하게 해주는 TDD용 스타일 . 코드형태가 JUnit과 거의 동일
    • ExpectSpec: DSL로 Testcase 작성을 하게 해주는 TDD용 스타일

• TDD vs. BDD
  

  • 서로 상호 보완적인 관계
  • BDD는 TDD의 관점에서 확인하기 어려운 유저 시나리오의 흐름 확인 가능
  • BDD의 테스트 케이스만으로는 완벽하지 못하므로, 시나리오에서 사용되는 각 모듈을 TDD로 검증해야 기대되는 커버리지를 갖는다
  

DCI(Describe-Context-It) 패턴

Given/When/Then 구조와 비슷하지만 테스트 대상의 행동을 더 섬세하기 설명

키워드	설명	권장하는 명시항목
Describe	설명할 테스트 대상을 명시	테스트 대상이 되는 클래스, 메소드 이름 명시
Context	테스트 대상이 놓인 상황 설명. 영어로 작성되는 경우 with 또는 when으로 시작	테스트할 메소드에 입력할 파라미터를 설명
It	테스트 대상의 행동 설명. 단순할수록 좋다	테스트 대상 메소드가 무엇을 리턴하는지 설명

• 장점
  • 계층 구조의 테스트 코드 생성 가능
  • 스코프 범위에만 유의하여 테스트 코드를 추가하고 읽기 가능
    • 프레임워크가 DCI 패턴을 지원해주는 경우, 스코프 범위에 해당하는 테스트 대상과 테스트 조건, 결과가 확실하게 구분됨
  • 누락된 테스트 코드를 찾기 쉬움
    • 높은 테스트 커버리지가 필요한 경우 유리

---

Ref.
BDD (Behaviour-Driven Development)에 대한 간략한 정리
JUnit5로 계층 구조의 테스트 코드 작성하기
kotest가 있다면 TDD 묻고 BDD로 가!