TDD와 BDD 무엇이 다를까?

nathan·2022년 2월 22일
0

TDD와 BDD 무엇이 다를까?

  • TDD도 잘 모르는데 이번엔 BDD라고 한다..
    이번 기회에 둘은 무엇이 다르고, 어떤 때에 사용하는 것인지 "가볍게" 파헤쳐 보고자 한다.

  • if(kakao)2020을 듣고 정리를 한 내용입니다.


TDD란?

  • Test Driven Development의 준말로, 테스트 주도 개발이라고 한다.
  • 테스트 주도라는 것은 테스트를 미리 작성하고 해당 테스트가 정상적으로 통과될 때까지 개발을 진행한다는 의미를 지닌다.

🧐 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 :
      • "등록 결과가 포함된 검수 진행 목록 화면으로 이동한다"
      • "검수 등록 실패 사유가 화면에 표시되어야 한다."
  • 이렇게 기획 단계에서 빠진 부분들을 일정 연기 없이 추가하려다가 누더기 코드가 잔뜩 쌓이게 되는 것을 BDD를 통해 방지할 수 있게 된 것이다!!

  • BDD를 통해 시나리오 검증 및 리스크 감소 효과를 볼 수 있다. (탄탄한 설계의 밑거름이 된다.)


TDD와 BDD의 차이점 (요약 표)

TDDBDD
테스트 코드의 목적은?기능 동작의 검증서비스 유저 시나리오 동작의 검증
테스트 코드의 설계중심은?제공할 모듈의 기능 중심서비스 사용자 행위 중심
테스트 코드 설계 재료는?모듈 사양 문서
(개발자가 작성)
서비스 기획서
(서비스 기획자가 작성)
어떤 프로젝트에 적합한가?모듈/라이브러리 프로젝트서비스 프로젝트
장점은?설계 단계에서 예외 케이스들을 확인 가능설계 단계에서 누락된 기획을 확인 가능

🌞 마무리하며..

  • TDD, BDD 말로만 듣던 내용을 직접 정리해보면서 개념을 구체화할 수 있었던 좋은 기회였다.
  • 단위 테스트만 연습하는 단계이지만, TDD, BDD를 직접 내 손으로 해볼 수 있는 날이 빨리 오면 좋겠다.
profile
나는 날마다 모든 면에서 점점 더 나아지고 있다.

0개의 댓글