[NEXTSTEP] TDD와 BDD

들어가기 전에

1주차 계산기 과정에서는 TDD와 BDD에 대한 게시물을 읽지 못하고 시작하여 "테스트코드"를 선행하여 만든 것이 아닌, 개발을 위한 코드를 모두 작성하고 난 후에 만들었다.

 

그러다보니, 내가 수정이 필요한 부분은 개발 과정 속에서 대부분 발견 되어 "과연 테스트코드가 필요한가?" 에 대한 의문을 안고 있었는데 이는 순서가 달라서 겪었던 생각이 아니였을까라는 느낌이 든다.

 

만들어야 하는 어플리케이션이 요구하는 기능을 올바르게 테스트케이스에 반영시켜서, 내가 짠 코드가 올바르게 적용 되고 있는지 확인하는 작업을 "2주차 - 레이싱 경주" 에 반영 시키기 위해 TDD와 BDD 내용을 정리 해보고자 한다.

TDD

정의

테스트 케이스를 미리 정의하고, 코드를 작성하는 방법을 의미합니다.

흔히들 개발전에 테스트 코드를 짜는게 TDD라고만 생각할 수 있는데, 그보다 본질적인 의미는 문제를 정의하고, 그 해답을 찾아가는 과정이라는게 TDD의 기본 취지입니다.

 

장점

테스트를 먼저 작성하기 때문에 전체 코드에서 얼마나 많은 코드가 테스트되는가를 측정하는 테스트 커버리지 비율이 자연스럽게 높아진다.

버그때문에 발생하는 시간 낭비 줄여주고, 코드가 원하는 바를 명확히 달성하는지 쉽게 확인 가능하다.

 

좋은 테스트 코드란?

실행 속도가 빨라야 함.

내부 구현(테스트하지 않는 부분)을 변경했다고 해서 테스트가 실패하면 안된다. 인터페이스(입출력 위주)를 중심으로 작성.

버그를 찾을 수 있어야 한다. 만들었다고 끝이 아님 테스트 시나리오를 잘 설정해야 함.

테스트 결과에 일관성이 있어야 한다. 코드가 변하지 않았다면 테스트 결과는 항상 동일 해야 한다.

의도가 명확히 드러나야 한다.

 

BDD

테스트자체가 요구사항이 될 수 있도록 작성하는 개발 방법론을 의미한다.

아래 3가지의 조건을 바탕으로 행동 방식(Should) 를 설정한다.

 

1. 특정 값이 주어지고(Given)
2. 어떤 이벤트가 발생했을 때(When)
3. 그에 대한 결과를 보장해야 한다(Then).