kotest가 있다면 TDD 묻고 BDD로 가!

카카오 if 컨퍼런스

TDD / BDD란?

개발이 테스트 주도로 진행된다는 의미.

테스트케이스를 작성하고 테스트를 돌려 실패한 코드들을 수정한 다음 다시 테스트를 반복하는 개발

일반적으로 테스트케이스를 만드는 것은 이미 작성된 코드의 검증을 뜻함.

테스트 작성 시점을 기준으로 고려한다면 테스트케이스가 먼저, 그다음 코드여야 TDD이다.

테스터블하다는 것은 말 그대로 테스트 가능한. 즉 테스트하기 쉽게 만들어진 코드.

테스트를 쉽게 하기 위해서는 테스트할 모듈의 역할이 명확해야 한다.

이렇게 하기 위해서는 모듈의 역할을 단순화 하는 것이 필요하다.

모듈 크기를 줄이는 설계를 유도하고 모듈 또는 계층간의 커플링도 적게 만들어 유지보수 및 확장을 쉽게 하자.

지속적인 테스트 케이스 유지 보수가 필요한데 일정관리에서 부담이 크니까. 귀찮음도..

기술 부채의 악순환. (TC 창작의 고통 → 일정 지연의 압박 → 테스트를 포기한 개발/배포)

이 악순환을 끊기 위해서라도 테스트 작성에 들어가는 비용을 받아들이자.

테스트 케이스를 상상해서 만드는 것 보다 이미 작성된 요구사항이나 기획서가 바로 테스트 케이스가 된다면 테스트 케이스 창작의 고통이 해소 될 수 있음.

TDD에서 파생된 개발 방법론.

테스트 케이스 작성을 이미 정의된 사용자 행위로 작성하면 된다.

이 사용자 행위들은 기획서에 적혀 있을 것이다. 이를 개발자가 코드로 옮기면 된다.

Given(주어진 환경) → When(행위) → Then(기대 결과)

TDD로 가능할 것 같은데 왜 굳이 BDD로 하는가? (다음챕터)

TDD와 BDD는 테스트케이스 목적의 관점에서 차이가 있다.

TDD의 테스트 케이스는 테스트할 모듈의 기능을 확인하는 관점에서 작성이 되고

BDD의 테스트 케이스는 시나리오 주체를 기준으로 한 행위를 확인하기 위한 관점에서 작성이 된다.

BDD는 TDD의 관점에서 확인하기 어려운 유저 시나리오의 흐름을 파악할 수 있다.

BDD로 시나리오 검증을 하고 BDD의 시나리오에 사용되는 모듈들은 TDD의 테스트 케이스로 검증해야 기대하는 테스트 커버리지를 가질 수 있다.

TDD와 BDD는 상호 보완적인 관계

BDD는 기획 시나리오의 빈틈들을 테스트 케이스 작성 단계에서 확인할 수 있는 장점이 있다.

코드 작성전에 발견할 수 있기 때문에 큰 변경을 해야 할 상황을 피할 수 있음.

해보니까 서비스 개발완료 이후 추가적인 기능들에 대한 검증 불안이 많이 줄었다.

정리하자면 BDD를 사용하면