1. Overview

현재 내가 속한 팀에서 기존 프로젝트에 sonarqube와 JaCoCo를 활용하여 CI를 적용하고 있다.

CI를 적용하고자 하니,, 기존에 작성된 테스트코드가 개발자 각각 개인 스타일대로 작성됐거나 테스트케이스가 잘못된 테스트 클래스에 위치해 있는 등의 문제가 있어 테스트코드 컨벤션부터 손을 보게 되었고, DCI패턴과 given when then 패턴을 알아보는 과정에서 TDD와 BDD, ATDD의 차이점이 정확히 무엇인지 궁금하여 알아보게 되었다.

2. TDD와 BDD, ATDD

TDD와 BDD의 차이점을 먼저 이해하고, BDD와 ATDD의 차이점을 이해하면 빠르다.

먼저 TDD부터 알아보자.

TDD

테스트 주도 개발은 테스트가 주도하는 개발 방법론을 의미한다. 자동화된 테스트로 개발을 이끌어나가는 방식이다.

TDD는 단 두가지 단순한 규칙만을 따른다.

• 오직 자동화된 테스트가 실패한 경우에만 새로운 코드를 작성한다.
• 중복을 제거한다.

많은 경우에 TDD와 단위테스트를 혼동하는 경우가 있지만 TDD의 결과물이 단위테스트일 뿐 TDD와 단위테스트는 목적이 다르다고 할 수 있다.

"비즈니스 로직을 먼저 구현하고 단위테스트를 작성하였더니 코드 설계, 모듈들 간에 의존성 등등에서 여러가지 문제점이 발생하여 유지보수가 점점 힘들어진다.. 이를 테스트를 먼저 작성하여 설계가 좋은 코드를 만들 수 있지 않을까?" 에서 시작된 것이 TDD라고 한다.

TDD는 개발 방법론이므로 설계 / 개발 관점에서 이해해야한다. TDD는 테스트 케이스를 먼저 작성하고 비즈니스 로직을 구현한다.

1. 먼저 실패하는 테스트코드를 작성한다. (RED)

테스트코드를 돌려 실패가 뜨는 것을 확인한다. 컴파일 조차 안될 수 있다.

2. 테스트코드를 성공하기 위한 실제 코드를 작성한다. (GREEN)

좋은 코드를 여기서 고민하지 않아도 된다. 테스트코드가 통과하기만 하면 된다.

3. 중복 코드 제거, 일반화 등의 리팩토링을 수행한다. (BLUE)

블루 단계에서 리팩토링을 수행하여 중복을 제거한다.

이 과정을 반복한다.

테스트 케이스를 먼저 정의하는 것이 왜 좋을까?

유닛 단위로 테스트를 하려면 유닛간의 종속성을 끊어낼 수 있도록 설계되어 있어야 하기 때문이다.

종속성의 커플링이 약한 설계가 유지보수가 좋다고 할 수 있는데 결국 단위테스트 작성을 통해 자연스레 커플링이 약한 좋은 설계를 얻어낼 수 있는 것이다

이런 측면에서 TDD가 순수하게 단위테스트만을 위해 존재한다 할 수 없다.

실제 TDD는 많이 이루어지는가

TDD는 많은 개발자들이 대부분 장점에 공감하지만 실제 개발 단계에서 TDD가 잘 이루어지지는 않는다. 왜냐하면 테스트케이스 유지보수, 일정관리 관점에서 리소스 부담이 매우 크기 때문이다.

TDD에서 테스트케이스를 창작하고 고민하는 모든 것은 비용이다. 이미 작성된 요구사항이나 기획서가 바로 테스트케이스가 된다면 그런 관점에서 비용이 줄어들 것이다. 그것이 바로 BDD이다.

BDD

행위 주도 개발은 테스트 주도 개발(TDD)에서 파생된 개발 방법론이다.

BDD는 주로 시스템 동작의 행위를 기반으로 한다. 다음은 BDD를 한줄로 이해할 수 있는 글귀가 있어 퍼왔다.

코드를 작성하기 전에 코드가 수행할 행위에 대한 명세를 먼저 작성해야 한다고 하면 다들 쉽게 이것이 좋은 습관이라고 수긍하게 되지 않을까? 아직 존재하지 않은 코드에 대해 테스트를 작성하기 보다는, 행위에 대한 명세를 작성하는 것이라고 생각하면 직관적으로 쉽게 이해가 된다. 이것이 BDD의 핵심이다.

BDD는 비 기술적 언어를 사용하여 더 많은 사람들이 쉽게 이해하도록 하며 고객과 개발자의 관점에서 시스템이 어떻게 작동해야 하는지에 초점을 맞춘다.

BDD에서 주로 사용하는 디자인 패턴은 다음과 같다.

Given-When-Then Pattern

• Given : 시나리오 진행에 필요한 값을 설정한다.
  ex) 사용자가 로그인이 된 상태에서
• When : 시나리오를 진행하는데 필요한 조건을 명시한다.
  ex) 포인트 조회를 한다면
• Then : 시나리오를 완료했을 때 보장해야 하는 결과를 명시한다.
  ex) 사용자의 포인트가 보여진다.

Describe-Context-It Pattern

좋은 게시글이 있어 공유로 대체한다!
https://johngrib.github.io/wiki/junit5-nested/

ATDD(Acceptance Test Driven Development)

인수 테스트 주도 개발은 말 그대로 인수테스트가 주도하는 개발 방법론을 의미한다.

인수테스트가 무엇인지 궁금하다면 이전 게시글을 참고하자. (단위테스트, 통합테스트, 인수테스트란)

BDD와 ATDD는 유사하나 BDD는 개발자 관점에서 기능의 동작에 더 중점을 두는 반면 ATDD는 사용자 시나리오 관점에서 정확한 요구 사항을 캡처하는 데 중점을 둔다.

구현 전에 사용자, 테스터 및 개발자가 인수 조건(Acceptance Criteria)을 정의한다. 이를 통해 모든 프로젝트 구성원이 수행해야 할 작업과 요구 사항을 정확히 이해할 수 있도록 도와준다.

이전 게시글에서도 말했듯 백엔드 시스템에서는 소프트웨어 인수테스트를 위해 주로 API 에 인수테스트 코드를 작성한다. 그 과정에서 주로 RestAssured를 사용한다.

마무리

TDD, BDD, ATDD가 무엇인지 알아보았다.
실제 개발단계에 들어간다면 셋 중 하나만 선택해서 적용해야할까? 아니다!
저 3개는 서로 상호 보완적인 관계로 필요한 부분에 같이 사용될 수 있다.(https://tv.kakao.com/v/414004682)