[우아한 Tech] 우아한 ATDD

[우아한 Tech] 우아한 ATDD

2021년 3월에 진행된 우아한 테크 세미나에서 류성현님의 '우아한 ATDD' 스트리밍 영상을 보고 정리한 내용입니다.

• ATDD(인수 테스트 주도 개발)는 요구사항에 대한 인수 테스트를 이용하여 요구사항을 명확히 하고 모든 팀원이 요구사항에 대한 공통의 이해를 바탕으로 개발을 진행하는 방법.

TEST vs TDD

• TEST : 구현 -> 테스트(검증) like 일기

• TDD : 테스트(요구사항) -> 구현 + @ like TODO List

• BDD : 행위(요구사항) -> 구현

• ATDD : 인수 테스트(요구사항) -> 인수 테스트 -> 구현

...(요구사항) - User Story

1. 논의 - Discuss
  - 기획/개발/QA 함께 인수 조건 회의 참여
  - 화면 기반으로 작성할 경우 이해도가 높음
  - 모든 인수 조건을 다같이 만드는건 비효율적(기본적인 부분부터 진행)

...(인수 조건 정의) - Acceptance Criteria

2. 정제 - distill
  - 논의 단계의 결과를 바탕으로 세부적인 부분 고려

...(인수 테스트) - Acceptance Test

3. 개발 - Develop
    3-1. Acceptance Criteria
    3-2. Acceptance Test
    3-3. Mock 서버 DTO 정의
    3-4. 문서화
    3-5. 개발(TDD)

...(소프트웨어) - Software

4. 데모 - Demo

...(사업 가치) - Business value

ATDD Develop Process

요구사항

• 사용자 스토리 (누가/무엇을/왜)

  강사는
  강의료를 환불해주기 위해
  수강생의 수강을 취소할 수 있다.

인수 조건 정의

• 인수 테스트가 충족해야하는 조건

• 인수 조건을 표현하는 시나리오 기반 표현 방식 사용(ex. Given/When/Then)

• 인수 조건 작성 방법

  1. 검증하고자 하는 when 구문 먼저 작성

  2. 기대 결과를 의미하는 then 구문 작성

  3. when과 then에 필요한 정보를 given을 통해 마력

3. given - 사전 조건
  수강생이 수강 신청
  과정의 남은 기간이 절반 이상
1. when - 검증 대상
  강사는 특정 수강생의 수강 상태를 취소 요청
2. then - 기대 결과
  특정 수강생의 수강 상태가 취소
  특정 수강생의 결제 내역이 환불
----------------------------------
example)
given - 사전 조건
  강사는 강의를 생성
  강사는 강의를 신청 가능 상태로 변경
  강의 모집 인원만큼 신청을 받음
when - 검증 대상
  회원이 수강 대기 신청 요청
then - 기대 결과
  회원은 수강의 수강 대기자로 등록

인수 테스트 작성

• 인수 조건을 검증하는 테스트
• 실제 요청/응답 환경과 유사하게 테스트 환경 구성

테스트 도구

테스트 서버(환경)

• @SpringBootTest
• webEnvironment 속성을 사용하여 테스트 서버의 실행 방법을 설정
• 실제 웹 환경과 유사한 RANDOM_PORT 설정 선택

테스트 클라이언트

• RestAssured
  • 실제 web environment(Apache Tomcat)을 사용하여 테스트
• MockMVC
  • @SpringBootTest의 webEnvironment.MOCK 과 함께 사용 가능
  • mocking 된 web environment 환경에서 테스트
• WebTestClient
  • @SpringBootTest의 webEnvironment.RANDOM_PORT 나 DEFINED_PORT와 함께 사용
  • Netty 를 기본으로 사용

조합

• @SpringBootTest / RANDOM_PORT + RestAssured
• @SpringBootTest / Mock + MockMVC

Tip

테스트 데이터 초기화

• 일괄 데이터 초기화
  • EntityManager를 활용한 테이블 이름 조회
  • 각 테이블 Truncate 수행
  • ID auto increment 값 초기화
• @DirtiesContext
  • 스프링 테스트 환경에서 캐싱된 Context를 사용하지 않게 설정
  • 매번 Context를 새로 구성하다 보니 많은 시간 소요

간단한 성공 케이스 우선 작성

• 동작 가능한 가장 간단한 성공 케이스로 시작
• 테스트가 동작하면 더 좋은 생각이 떠오를 수 있음

도메인부터 TDD

• 인수 테스트를 통해 시나리오 및 전반적인 기능에 대한 이해를 했다면, 핵심 기능에 대한 도메인 설계를 한 후 도메인 객체에 대한 TDD 수행

추천 흐름

• Top-Down 으로 방향을 잡고, Bottom-Up 으로 구현하기
• 인수 테스트 작성을 통해 요구사항과 기능 전반에 대한 이해 선행
• 내부 구현에 대한 설계 흐름 구상
• 설계가 끝나면 도메인부터 차근차근 TDD로 기능 구현
• 도메인 설계가 복잡하거나 설계가 어려울 경우 이해하고 있는 부분 먼저 기능 구현
• 인수 테스트 요청을 처리하는 부분부터 진행 가능

기능 구현

• 인수 테스트를 충족하기 위한 코드 구현
• 기능 구현은 TDD로 진행 가능

ATTD 장/단점

장점

• 다른 포지션의 관점은 물론 업무 프로세스도 간접적으로 익힐 수 있음
  • 다른 포지션의 진행 상황에 대한 인지와 이해도가 높아짐

단점

• 인수 조건 정의의 어려움
  • 문서 관리에 대한 고민이 필요
• 리소스
  • 기획/개발을 두 번 작업하는 느낌

Q/A

TDD vs ATDD

• TDD는 메서드 단위의 작은 기능 검증이라면,
• ATDD는 사용자가 사용하는 기능 전체를 테스트하는 큰 범위의 TDD
  • ATDD 사이클 내에 TDD 사이클이 포함
  • 보통 1개의 인수 테스트에서 N개의 단위테스트

통합 테스트 vs 인수 테스트

• 통합 테스트 : 각각의 단위들이 유기적으로 잘 동작하는지 검증
• 인수 테스트 : 사용자 스토리기반 시나리오 관점에서 기능 테스트

기준을 나누기 보다 인수 테스트는 통합 테스트의 특징을 가지고 있으면서, 시나리오 관점으로 진행된다는 생각을 하는 것이 좋을 듯.

Reference

Youtube