TDD와 BDD 무엇이 다를까?
-
TDD도 잘 모르는데 이번엔 BDD라고 한다..
이번 기회에 둘은 무엇이 다르고, 어떤 때에 사용하는 것인지 "가볍게" 파헤쳐 보고자 한다. -
if(kakao)2020을 듣고 정리를 한 내용입니다.
TDD란?
Test Driven Development의 준말로, 테스트 주도 개발이라고 한다.- 테스트 주도라는 것은 테스트를 미리 작성하고 해당 테스트가 정상적으로 통과될 때까지 개발을 진행한다는 의미를 지닌다.
- 이미지 출처 : TDD 대 BDD – 예제를 통해 차이점 분석
테스트 코드 작성 -> 실패 -> 코드 작성 후 다시 테스트를 반복하며 개발하게 된다.
🧐 Test Case를 작성한다고 해서 TDD라고 하나요?
- TDD는
테스트케이스를 우선적으로 작성하고, 그 다음 코드를 작성하는 방법이다.- !TDD(not TDD)는
코드를 우선적으로 작성하고, 그 다음 테스트를 하는 방법이다.
- 테스트 케이스를 먼저 작성하고 코드 설계를 하게 되면, 코드 작성이 테스트 가능하게끔 이루어 진다는 장점이 있다.
- 이를 "Testable" 즉 테스트가 가능한 설계로 짜여진 코드 작성이 가능하다고 말한다.
그렇다면, Testable Code는 어떤 장점을 가질까?
- 우선, 테스트를 쉽게 하기 위해서는 모듈의 역할이 명확해야 한다.
- 이를 위해서는 모듈의 역할 단순화가 필요하다.
Testable Code는 역할 단순화가 된 모듈의 작성이 가능하다.- 이를 통해 모듈 또는 계층간의 coupling 현상을 줄여 유지보수와 확장이 용이하다는 장점을 가질 수 있게 된다.
이렇게 좋은 TDD를 왜 안할까?
왜 TestCase 작성을 안할까?
- 대부분의 개발자들이 테스트의 중요성을 알고 있고, TDD 도입에 따른 장점도 공감하고 있다.
- But, 비용에 대한 부담때문에 실천이 잘 되고있지 않은 것이 현실이다.
아래와 같은 흐름을 통해 기술 부채의 악순환이 뒤따르게 된다.
- Test Case 창작의 고통
- 일정 지연에 대한 압박
- Test를 포기한 개발 및 위험한 배포
위 같은 상황을 막기 위해서라도 TDD를 해야한다.
- 부담을 어느정도 감수해야하는 현실..
- 그러나 단순한 변수명 정하기도 힘든 것이 사실이다..
- 어떻게 이러한 현실을 타개할 수 있을까?
... 테스 형도 모른다고 한다.
- 정답은 없지만 해답은 존재한다는 말이 있다.
- 선배 개발자들은 그 해답을 BDD에서 찾았다.
- 그렇다면 BDD는 무엇이며, BDD만이 진리일까? 알아보자.
BDD란?
-
Behavior Driven Development의 준말로, 행동 주도 개발이라고 한다. -
TDD에서 파생된 개발 방법론으로써, 개발자와 비개발자 간의 협업 과정을 녹여낸 방법이다.
-
사용자의 행위를 작성하고 결과 검증을 진행하는 방식으로 이루어진다.
-
BDD로 테스트코드를 작성함에 따라 설계 또한 행위의 중심이 되는
도메인 기반의 설계가 된다. -
TDD에 쓰이는 고민의 시간은 곧 비용이 된다.
- Test Case를 상상으로 만드는 것보다 이미 작성된 요구사항이나 기획서가 Test Case가 된다면, 그런 비용이 감소할 수 있다!
그런데 어떻게 요구사항이나 기획서가 TC가 될 수 있나요?
- 요구사항이나 기획서에는 이미
사용자의 행위들이 정의되어 있다. - 이것을 코드로 옮겨내면 곧, Test Case가 되는 것이다.
어떻게 BDD를 할 수 있나요?
-
선배 개발자들의 노력으로 이미 정해진 형식을 만나볼 수 있었다.
-
아래 세 가지 틀을 통해 요구사항을 하나하나씩 구조화된 시나리오로 작성할 수 있다.
Given: 사용자 행위 시 주어진 환경When: 실제 사용자의 행위Then: 그 행위에 따른 기대 결과
-
Example (이모티콘 스튜디오 검수 등록 화면 기획서 기반 BDD TestCase)
- Given : "본인 인증된 사용자가 로그인 된 상황에서"
- When :
- "검수 정보를 입력하고, 검수 등록 버튼을 누르면"
- "검수 정보를 미입력하고, 검수 등록 버튼을 누르면"
- Then :
- "등록 결과가 포함된 검수 진행 목록 화면으로 이동한다"
- "검수 등록 실패 사유가 화면에 표시되어야 한다."
-
예시를 보면 기획서의 내용이 그대로 담겨있음이 확인 가능하다.
-
이제 Test Case에 대한 부담이 줄어들었을 뿐만 아니라, 요구사항이나 기획서를 꼼꼼히 읽기 때문에 개발자가 서비스에 대한 이해도 또한 높아질 수 있다고 한다.
-
그런데 이는 TDD를 그냥 확장한 방식이라고 해도 될텐데, 굳이 BDD라고 따로 부르는 이유가 뭘까?
TDD와 BDD의 차이를 알아보자
TDD와 BDD는 무엇이 다르며, 둘 중 하나만 꼭 선택해야 하는 것일까?
- TDD와 BDD는 TestCase 목적의 관점에서 차이를 보인다.
- TDD의 TC : 테스트할 모듈의 기능을 확인하는 관점에서 작성
- add(1,1)이 2인지 확인
- BDD의 TC : 시나리오 주체를 기준으로 한 행위를 확인하기 위한 관점에서 작성
- 사용자가 "="를 눌렀을 때, 1+1의 값이 2가 화면에 표시되는지 확인
- 마치 BDD의 Test Case가 TDD의 Test Case를 포함하는 것 처럼 보인다.
- 실은 이 둘은 포함관계가 아니다. 다음의 이미지를 보자.
- 이처럼 BDD는 TDD에서 파생된 개념이지만, TDD에서 확인할 수 없는
유저 시나리오의 흐름을 확인할 수 있다. - 허나 BDD의 Test Case만으로는 완벽할 수 없다.
- 따라서 시나리오의 흐름에 대한 부분은 BDD로 하되, 시나리오와 관련된 각 모듈들은 TDD로 검증을 하면 된다.
- 그래야 기대하는
Test Coverage(테스트가 충분함을 가지는지에 대한 척도)를 가질 수 있다.
즉, BDD와 TDD는 상호 보완적 관계이다.
- TDD 사이클의 Test Case가 모두 통과되더라도 BDD 사이클에서 Test Case가 실패할 가능성도 있다.
- 계산기 예제처럼
add함수 자체는 작동을 잘 하더라도, 결국 사용자가 원하는 결과물을 얻지 못하기 때문에, BDD의 Test Case에서 실패할 수 있게 된다.
- 계산기 예제처럼
추가적인 BDD의 장점
- Test Case를 만들다보면, 예외적인 입력 값에 대한 Test도 추가하고, Coverage를 높여가게 된다.
- 문제는 이런 경우가 배포까지 진행된 상태에서도 종종 발생하게 된다는 점이다.
- 이러한 리스크를 줄이기 위해서는 기획에 대한 검토가 충분히 이루어져야 한다.
- BDD는 기획 시나리오의 빈틈들을 Test Case 작성시에 확인할 수 있다는 장점이 있다.
- 즉, 재설계시 코드 작성 전이라 비용 리스크가 적다.
- 따라서 이렇게 입력 값에 대한 설계를 놓치게 되는 경우를 방지할 수 있게 한다.
-
아래 예제를 통해 인증 방식 이슈가 추가로 기획이 필요하다는 것을 알 수 있게 된다.
-
Example (이모티콘 스튜디오 검수 등록 화면 기획서 기반 BDD TestCase)
- Given : "본인 인증된 사용자가 로그인 된 상황에서"
- "본인 인증 안된 사용자가 로그인 된 상황에서"
- "본인 인증이 어려운 미성년 사용자가 로그인 된 상황에서"
- When :
- "검수 정보를 입력하고, 검수 등록 버튼을 누르면"
- "검수 정보를 미입력하고, 검수 등록 버튼을 누르면"
- Then :
- "등록 결과가 포함된 검수 진행 목록 화면으로 이동한다"
- "검수 등록 실패 사유가 화면에 표시되어야 한다."
- Given : "본인 인증된 사용자가 로그인 된 상황에서"
-
이렇게 기획 단계에서 빠진 부분들을 일정 연기 없이 추가하려다가 누더기 코드가 잔뜩 쌓이게 되는 것을 BDD를 통해 방지할 수 있게 된 것이다!!
-
BDD를 통해 시나리오 검증 및 리스크 감소 효과를 볼 수 있다. (탄탄한 설계의 밑거름이 된다.)
TDD와 BDD의 차이점 (요약 표)
| TDD | BDD | |
|---|---|---|
| 테스트 코드의 목적은? | 기능 동작의 검증 | 서비스 유저 시나리오 동작의 검증 |
| 테스트 코드의 설계중심은? | 제공할 모듈의 기능 중심 | 서비스 사용자 행위 중심 |
| 테스트 코드 설계 재료는? | 모듈 사양 문서 (개발자가 작성) | 서비스 기획서 (서비스 기획자가 작성) |
| 어떤 프로젝트에 적합한가? | 모듈/라이브러리 프로젝트 | 서비스 프로젝트 |
| 장점은? | 설계 단계에서 예외 케이스들을 확인 가능 | 설계 단계에서 누락된 기획을 확인 가능 |
🌞 마무리하며..
- TDD, BDD 말로만 듣던 내용을 직접 정리해보면서 개념을 구체화할 수 있었던 좋은 기회였다.
- 단위 테스트만 연습하는 단계이지만, TDD, BDD를 직접 내 손으로 해볼 수 있는 날이 빨리 오면 좋겠다.
