[Backend 개발자 면접 준비] TDD / BDD 란?

 

 

테스트 코드를 작성하면서 TDD, BDD 라는 용어를 한번씩 들어봤을 것이다.

둘다 모두 테스트 코드 작성과 관련있는 용어이며, 이것이 어떤 의미를 가지며 어떤 차이가 있는지 알아보고자 한다.

 

TDD (Test Driven Development)

TDD란 말 그대로 테스트 주도로 개발을 이끌어 나가는 것이다.

TDD는 매우 짧은 개발 서클의 반복에 의존하는 소프트웨어 개발 프로세스이다.

즉, 테스트를 먼저 작성하고 나서, 테스트가 정상적으로 돌아갈 때 까지 테스트를 하면서 코드를 작성하는 작업이라고 볼 수 있다.

원하는 작업이 제대로 돌아갈 때까지 테스트와 코드 작성을 무한대로 반복하며 개발을 하면 된다. 

 

* 장단점

- 개발하다 꼬여도 테스팅을 돌려봄으로써 안심하고 진행할 수 있음

- 보다 객체지향적이고 확장 가능이 용이한 코드, 재설계의 시간을 단축시킬 수 있는 코드, 디버깅 시간이 단축되는 코드

- 코드량이 늘기 때문에 빠른 생산성이 요구되는 시점에서 TDD는 큰 걸림돌일 수 있음

 

BDD (Behavior Driven Development)

BDD는 말 그대로 행동 주도 개발이다. 사용자의 행위까지 생각하고 테스트하며 개발한다. 

BDD는 TDD의 한 종류로, 프론트엔드에서 조금 더 장점이 두드러지는 경향이 있다. 메소드 위주의 TDD보다 행동을 조금 더 강조하기 때문이다. 

 

- TDD와 거의 유사하긴 하지만. 차이가 있다면 TDD는 테스트 자체에 집중해 개발하는 방면, BDD는 비즈니스 요구사항에 집중하여 테스트 케이스를 개발한다

- 테스트 케이스 자체가 요구사양이 되도록 하는 개발 방식

- TDD 를 결합해 시나리오 테스트까지 하는것

- 시나리오는 어디서부터 테스트를 시작할지, 어떤 것을 테스트하고 어떤 것을 하지 않을지, 한 번에 얼마만큼을 테스트할지, 테스트에 어떤 이름을 붙일지, 테스트가 왜 실패했는지 등에 대한 고민을 해결해줌

- 메소드 이름을 "이 클래스가 어떤 행위를 해야한다(should do something)" 라는 식의 문장으로 작성해 "행위"를 위한 테스트에 집중

 

즉, BDD는 TDD에서 파생된 개발 방법론으로, 개발자와 비개발자의 협업 과정을 녹여낸 방법이다. 

 

BDD는 시나리오를 기반으로 테스트 케이스를 작성하며 함수 단위 테스트를 권장하지 않는다. 이 시나리오는 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 레벨을 권장한다. 하나의 시나리오는 Given, When, Then 구조를 가지는 것을 기본 패턴으로 권장하며 각 절의 의미는 다음과 같다.

Feature : 테스트에 대상의 기능/책임을 명시한다.
Scenario : 테스트 목적에 대한 상황을 설명한다.
Given : 시나리오 진행에 필요한 값을 설정한다.
When : 시나리오를 진행하는데 필요한 조건을 명시한다.
Then : 시나리오를 완료했을 때 보장해야 하는 결과를 명시한다.

테스트 대상은 A 상태에서 출발하며(Given) 어떤 상태 변화를 가했을 때(When) 기대하는 상태로 완료되어야 한다. (Then)

또는 Side Effect가 전혀 없는 테스트 대상이라면 테스트 대상의 환경을 A 상태에 두고(Given) 어떤 행동을 요구했을 때(When) 기대하는 결과를 돌려받아야 한다. (Then)

 

 

 

 

Reference Link

https://mingule.tistory.com/43

https://blog.naver.com/rkdudwl/221973507455

https://www.popit.kr/bdd-behaviour-driven-development%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B0%84%EB%9E%B5%ED%95%9C-%EC%A0%95%EB%A6%AC/