[웨비나후기]3월 우아한테크세미나 : 우아한 ATDD

웨비나 소개 및 후기

테스트의 중요성은 익히 알고 있지만 코드를 짜기 급급한 나는 테스트 주도 개발을 해본 적이 없다.
이번 웨비나를 통해 간접적으로나마 우아한형제들에서는 어떻게 ATDD를 하는지 알 수 있어서 유익했다.
또 인수 테스트와 단위테스트에 대한 비교를 실제 사례로 들어볼 수 있어서 이해가 쏙쏙 되었다.
너무 재밌다! 토이프로젝트에 꼭 넣어보고싶다!

ATDD (인수테스트) 란?

TDD(단위테스트) 수행시 어떻게 시작하고 언제 끝나는 지가 모호한 경우가 많고 각 단위들이 잘 통합하는 지 확인하기 어렵다.
만약 인수테스트가 없다면 배포해서 기능 동작을 확인해야하며 페이지에서 테스트를 해야하고 수동으로 변경사항을 확인해야한다.
하지만 인수테스트가 있으면 배포없이 테스트로 대부분 검증이 가능해지며 인수 테스트로 스펙표현까지 가능하다.

• 시나리오(사용자 스토리) 기반으로 기능 테스트
• 장점
  • 배포없이 받는 빠른 피드백
  • 새로운 팀의 도메인과 서비스 흐름 파악에 큰 도움이 됨
  • 도메인 이해에 예상보다는 짧은 시간이 소요

ATDD 개발 프로세스

• ATDD 개발 프로세스: 시나리오 기반 표현 방식(Given:사전조건/When:검증대상/Then:기대결과)을 통한 인수 조건 정의 -> 인수 테스트 작성 -> 기능구현
• 즉 예제로 명세하기 -> 예제로 정제하기 -> 실행가능한 명세만들기

인수조건

인수조건 작성시 검증하고자하는 when 구문을 먼저 작성 후 기대 결과를 의미하는 then구문 작성하고 when과 then에서 필요한 정보를 given을 통해서 마련한다.

• 인수조건 예시1

  기능 : 강의 수강 대기 신청
  
  인수조건:
  - given: 강사는 강의를 생성했다. 강사는 강의를 신청 가능 상태로 변경했다. 강의 모집인원만큼 신청을 받았다.
  - when: 회원이 수강 대기 신청을 요청한다.
  - then: 회원은 강의의 수강 대기자로 등록되었다.
  
  인수테스트: 실제 요청/응답하는 환경과 유사하게 테스트 환경을 구성
  
  기눙구현: 코드작성. TDD로 진행할 수 있음

• 인수조건 예시2

  기능 : 강의 수강 대기 신청
  
  인수조건:
  - given: 수강생이 수강 신청을 하였다. 과정의 남은 기간이 절반 이상이다.
  - when: 강사는 특정 수강생의 수강 상태를 취소 요청을 한다.
  - then: 특정 수강생의 수강 상태가 취소된다. 특정 수강생의 결제 내역이 환불된다.
  
  인수테스트: 실제 요청/응답하는 환경과 유사하게 테스트 환경을 구성
  
  기눙구현: 코드작성. TDD로 진행할 수 있음

인수테스트

• 특징: Black Box 테스트(내부 구조나 작동과 연관이 없는 테스트)
• UI레벨 대신 API 레벨 인수테스트를 추천: 백엔드 개발자 입장에서 공수가 너무 많이 들기때문.

테스트도구

• 테스트 서버(환경): @SpringBootTest
  • 실제 웹 환경과 유사한 RANDOM_PORT 설정 선택
• 테스트 클라이언트: MockMVC, WebTestClient, RestAssured
• 테스트 환경+테스트클라이언트 조합
  • @SpringBootTest / Mock + MockMVC
  • @SpringBootTest / RANDOM_PORT + RestAssured (연사님 픽)

TDD 강연 추천

성공적인 ATDD 도입하기

1. 나혼자 ATDD
   • 토이 프로젝트로 충분히 경험 쌓기
   • 간단한 기능부터 적용해보기
   • 경험해보면서 상황에 맞는 방법 찾기
2. 실전 프로젝트 적용시
   • 아주 쉽게 시작할 수 있는 부분, 기본적인 기능부터 도입
3. 레거시 기반 인수 테스트 작성하기
   • 먼저 인수 테스트를 작성하여 기존에 구현된 기능을 보호하기
4. 인수 가이드 작성
   • 지속적인 리뉴얼, 버전업
5. 지속적인 피드백

기획 & QA와 함께하는 ATDD

• 기획 & QA 담당자에게 장점을 소개하며 설득하기
  • 개발 친화적인 용어는 제외하고 설명하기
    • EX) 추가적인 커뮤니케이션비용이 절약될거다.
    • EX) 테스트시간이 단축된다.
  • 기존 방식과 비교하여 장점 이야기하기
• 다같이 만드는 요구사항
  • 화면 기반으로 작성할 경우 이해도가 높음
  • 모든 인수 조건을 다같이 만드는 건 비효율적

실제 적용사례 후기

실제로 처음 조직에 적용했을때의 피드백

• 장점: Common Understanding 다른 포지션의 관점은 물론 업무 프로세스도 간접적으로 익힐 수 있음
• 단점: 인수 조건 정의가 어렵고 문서를 어떻게 관리해야할 지에 대한 고민이 필요

질의응답

Q. RestAssured를 사용하신다고 하셨는데 TestRestTemplate를 사용해서 백엔드만의 테스트를 가능하다고 생각하는데 RestAssured를 따로 사용하신 이유가 있으실까요?

TestRestTemplate 객체를 사용하지않는 이유는 공식문서에 다른 객체를 사용해라는 말이 있어서 곧 없어지겠구나생각을 했고 사용하는 면에 있어서도 RestAssured가 편했기에 사용했다. 각각 장단점이 있으니 직접 사용한 뒤 상황에 맞게 적용하면 될 것같다.

Q. 세미나를 들으면서 문득 궁금점이 생겼는데 어떤 기능 하나를 개발하고자 할 때 인수 테스트부터 작성하려고 하면 유닛 테스트에 비해 해결해야 하는 문제가 커서 TDD가 주는 빠른 피드백과 설계에 도움을 주는 장점이 많이 희석될 것 같다는 생각이 드는데요.

인수테스트 작성 비용과 사이클을 도는 데까지 드는 시간도 오래걸린다. 인수테스트 하나를 만든다면 그 안에 TDD가 포함되어있다. 도메인단위테스트만 만들어도 되지만 인수테스트는 요청과 응답이 명확하다는 장점이 있다.
인수테스트가 빠른 피드백을 주기는 힘들지만 해당 기능을 배포하지않고도 확인할 수 있다는 장점이 있다.

Q. 한글/영어로 각 테스트 메소드 작성하실때 어떤 컨벤션을 지키시는 중이신가요?

핵심이 되는 도메인이름작성후 when과 같이 요청을 하는 부분은 요청이라는 컨벤션을 넣어서 진행중이다. 언더바를 사용해서 처리하고 있고 팀원들과 회의하면서 진행하고 있다.

Q. ATDD를 작성 후 어떤 사이클로 실행하나요? 배포 전에? pr날릴 때??

인수테스트를 만들고 내부 기능을 TDD로 만든다. 기능 구현이 어느정도 끝나면 인수테스트를 한번 돌리고 배포전에는 모든 인수테스트를 통과해야 배포가 되게끔 하고있다. PR날릴때는 실행하지않는다.

Q. 테스트 커버리지를 수시로 확인하시나요?

불안감이 적은 수준으로 테스트코드를 작성하려고 노력하고 있고 코드리뷰라는 장치가 있기때문에 테스트 커버리지를 따로 확인하지 않고 있다.

Q.TDD도 아직 잘 안되는 팀인데, ATDD를 하기는 버거울 것 같은데 TDD를 먼저 도입을 하고 그 후에 ATDD를 도입하는게 괜찮을까요?

TDD보다 ATDD를 도입하는 것이 더 쉽게 접근할 수 있다고 생각한다. 적용하기 쉬운 부분부터 차근차근 적용하는 것을 추천한다. API 요청과 응답이 명확하기때문에 ATDD가 더 접근하기 쉽다. 우리 서비스의 핵심부분에 대해서만이라도 ATDD를 적용하여 경험을 쌓으면서 점차 확대하는 것이 좋을 것 같다.

Q. 설득하는 방법

변화를 만들기위해서는 본인이 인수테스트에 대한 자신감이 있어야한다. 생각치도 못한 예외상황을 빠르게 해결해야한다. 이를 위해서 토이프로젝트를 통해 기술을 쌓아야한다. 변화를 원하는 사람이 가장 늦게까지 야근한다. 그 속에서 가장 많이 성장하는 사람은 바로 나 자신이다. 개발자는 사라져도 리더는 사라지지않는다. 미래지향적인 생각을 가졌으면 좋겠다.

참고자료

아래는 ATDD이해를 위해 내가 추가적으로 학습한 자료이다.

• ATDD 개념
• 인수테스트 주도 개발 (Acceptance Test Driven Development)