TDD와 BDD

패스트 캠퍼스 강의 'The RED 백발의 개발자를 꿈꾸며'와 카카오 if - "Kotest가 있다면 TDD 묻고 BDD로 가!"를 보고 정리 하였습니다.

 

 

TDD와 BDD는 소프트웨어 개발 방법론에서 많이 쓰이는 것들이다. 이 두가지의 방법론은 전혀 다른 것이 아닌 테스트 코드를 작성하는 관점의 차이라고 볼 수 있다. 

 

나의 경우, 분명 테스트 케이스를 설계하여 자신의 기능을 검증하는 것은 반드시 필요하다고 생각하지만 테스트 과정을 설계하는 것 자체가 어렵기도 하고, 그 과정에서 시간을 많이 소비하게 되어 효율적이지 않은 것 같다.

 

TDD(Test Driven Development)

테스트로부터 시작하는 개발 방식(테스트 주도 개발)으로 기능을 구현하기 전에 테스트 케이스를 설계하고, 이 테스트를 통과할 수 있는 코드를 짜는 방법을 말한다.  이 방법론으로 개발을 진행할 경우 시간은 오래 걸리지만 결함이 거의 없다.

 

과정

1. 요구사항을 분석 및 이해하고, 관련된 테스트에 대해 설계

2. 테스트 케이스를 설정하였으면 테스트 코드로 변환

3. 테스트가 실패할 경우 실패 원인을 분석하여 코드 보완

4. 테스트가 모두 통과하였다면 코드를 재사용하기 쉽게 리팩토링 과정 진행

 

단위 테스트에서 적용되는 F.I.R.S.T 원칙

※단위 테스트 : 프로젝트에 필요한 모든 기능에 대한 테스트를 각각 진행하는 것을 의미

※통합테스트 : 여러 기능을 조합하여 전체 비즈니스 로직이 제대로 동작하는지 확인하는 것을 의미

• Fast : 테스트 코드의 실행은 빠르게 진행되어야 함. 따라서 서버와 DB를 활용하지 않고 가짜 데이터로 테스트 진행
• Isolated : 모든 테스트들은 서로 의존적이지 않고 독립적인 테스트가 가능해야 함. 그 자체만으로 실행 가능
• Repeatable : 테스트는 매번 같은 결과를 만들어야 함. 즉 서로 의존적이지 않아야 한다.
• Self-Validating : 테스트는 그 자체로 실행하여 결과를 확인할 수 있어야 함. 로그를 통해서 수동적으로 결과를 알면 안된다.
• Timely : 단위테스트는 비즈니스 코드가 완성되기 전에 구성하고 테스트가 가능해야 함.
• → TDD에 적합한 원칙이지만 실제로 적용되지 않는 경우도 있다.

 

테스트 전 고민해봐야 할 내용 (상황→실행→결과 검증 )

테스트 작성 순서

1. 당장 빠르게 구현할 수 있는 것 부터 고민 

ex) 암호의 강도 : 모든 조건 충족 VS 2개 조건 충족

 

2. 예외적인 경우를 우선적으로 그리고 정상적인 경우를 생각

ex)

암호 강도 검사 : 입력값이 null 인 경우 VS 2개 조건 충족

회원 가입 : 같은 ID 회원이 있는 경우 VS 같은 ID 회원이 없는 경우

주문 취소 : 주문이 이미 취소된 경우 VS 주문이 취소 가능한 경우

 

3. 예외적인 경우는 코드 구조에 영향을 주게 된다.

- 예외적인 경우를 나중에 하게 될 경우 코드 구조가 복잡해질 수 있다.

 

4. 테스트는 매우 작은 단계부터 점진적으로 진행하자.

- 상수리턴, 값 비교, 구현 일반화 순으로 진행

장점

• 코드의 안전성을 높일 수 있다.
• 모듈의 역할이 단순해지고 명확해진다. → 유지보수가 쉬워짐
• 모든 예외사항을 처리하기 때문에 결함이 거의 없다.
• 기능을 추가하거나 변경하는 과정에서 발생하는 Side-Effect를 해결할 수 있다.
• 불필요한 내용을 줄일 수 있다.

 

BDD(Behavior Driven Development)

기획서의 내용에 포함되어야 하는 내용

BDD는 행동 주도 개발 방법론으로 TDD와 크게 차이나지 않는다. 두 방법론은 상호 보완적인 관계로 봐야한다. 다만 차이점이라고 한다면 TDD는 테스트 자체에 신경을 쓰고, BDD는 비즈니스의 요구사항에 초점을 맞추어 테스트를 진행한다. 사용자의 행위를 고려한다. 사용자가 겪을 수 있는 다양한 시나리오(User Story)를  문서화하여 기획서에 로직을 정리한다. 어떠한 환경에서 일어나는 행위가 무엇인지, 그 행위로 발생되는 결과는 무엇인지 기록한다. 이와 같이 시나리오를 통해 테스트 케이스를 설계하고 코드 구현을 한다면 TDD에서 테스트케이스를 설계하는 과정에서 발생하는 시간적인 비용을 보다 더 줄일 수 있다(개발자 입장). 문서를 보고 테스트 케이스를 구할 수 있기 때문이다.

• TDD에서 파생된 개발 방법론
• 개발자와 비개발자간의 협업 과정을 녹여낸 방법
• 사용자의 행위를 작성하고 결과 검증을 진행
• BDD로 테스트 코드를 작성함에 따라 설계 역시 행위의 중심이 되는 도메인 기반 설계가 됨

좌) TDD 우)BDD

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

---

참고하면 좋은 사이트

좋은 단위 테스트의 속성(FIRST)