다음은 "3월 우아한테크세미나 - 우아한ATDD" 내용을 정리한 글입니다
세미나 - https://www.youtube.com/watch?v=ITVpmjM4mUE
인수 테스트
- 시나리오(사용자 스토리) 기반의 기능 테스트
- 인수 테스트의 도움
- 배포 없이 받는 빠른 피드백
- 새로운 팀의 도메인과 서비스 흐름 파악에 큰 도움이 됨
- 도메인 이해에 예상보다는 짧은 시간이 소요
- 인수 테스트를 기반으로 개발을 할 경우
- 기존 인수 테스트 장점
- 빠른 피드백을 받을 수 있음
- 회귀 오류를 잡아줄 꾸준한 테스트를 만들 수 있음
- 기존 기능을 망가뜨리지 않고 새 기능을 추가할 수 있음
- 인수 테스트를 작성하면서 구현할 대상에 대한 이해도 증진
- 작업의 시작과 끝이 명확해져서 심리적인 안정감에 도움
- 기존 인수 테스트 장점
- 인수 테스트 기반 구현 프로세스
- 인수 조건 정의 → 인수 테스트 작성 → 기능 구현
인수 조건 정의
- 인수 조건 작성하기
- 검증 하고자 하는 when 구문 먼저 작성
- 기대 결과를 의미하는 then 구문 작성
- when과 then에서 필요한 정보를 given을 통해 마련
- 인수 테스트의 특징
- Black Box 테스트 → 내부 구조나 작동과 연관이 없는 테스트
- UI 레벨이 아닌 API 레벨에서 인수 테스트를 작성
테스트 도구
- 테스트 서버(환경)
- @SpringBootTest : 테스트 환경에서 요청에 대한 응답을 하기 위한 설정
- webEnvironment : 테스트 서버의 실행 방법을 설정
- 실제 웹 환경과 유사한 RANDOM_PORT 설정 선택
- @SpringBootTest : 테스트 환경에서 요청에 대한 응답을 하기 위한 설정
- 테스트 클라이언트
- MockMVC, WebTestClient, RestAssured : 테스트를 위한 서버에 요청을 보내기 위한 클라이언트 객체 설정
- MockMvc vs WebTestClient vs RestAssured
- MockMvc
- @SpringBootTest의 webEnvironment.MOCK과 함께 사용 가능하며 mocking 된 web environment 환경에서 테스트
- WebTestClient
- @SpringBootTest의 webEnvironment.RANDOM_PORT 나 DEFINED_PORT와 함께 사용, Netty를 기본으로 사용
- RestAssured(이번에는 이것을 사용!)
- 실제 web environment(Apache Tomcat)을 사용하여 테스트
- MockMvc
- 테스트 데이터 초기화
- repository 활용을 통한 초기화
- 손쉽게 데이터 초기화가 가능하지만 구현이 달라지면 테스트 영향을 받기도 하고 유효성 검사 로직 없어 깨지기 쉬운 테스트가 될 수 있다
- 요청을 통한 데이터 초기화
- 테스트 객체를 이용하여 직접 호출 후 초기화를 한다. 이 경우 테스트가 다른 테스트에 영향을 주지 않아야 한다
- repository 활용을 통한 초기화
- 요청을 통한 데이터 초기화시 테스트 간 영향을 받지 않도록 하는 방법
- @DirtiesContext를 사용하는 방법
- 스프링 테스트 환경에서 캐싱된 Context를 사용하지 않게 설정
- 매번 Context를 새로 구성하다보니 시간이 많이 걸림
- 일괄적인 데이터 초기화 방법
- EntityManager를 활용하여 테이블 이름 조회
- 각 테이블 Truncate 수행
- ID auto increment 값 초기화
- @DirtiesContext를 사용하는 방법
테스트 코드 리팩터링
- 인수 테스트 작성시 중복되는 로직이나 코드가 길어지면 가독성이 떨어질 수 있다. 이런 경우의 리팩터링을 진행해보자
- 반복되는 코드는 메서드로 분리한다
- 중복되는 로직은 다른 인수 테스트에서 재사용할 수 있도록 클래스를 분리해본다
- 가독성을 키우기 위해 테스트 메서드를 한글로 작성해본다
인수 테스트 코드 작성 팁
- 간단한 성공 케이스 우선 작성
- 동작 가능한 가장 간단한 성공 케이스를 우선 작성해본다
- 그 후 테스트가 동작하면 더 복잡한 케이스를 작성하거나 다른 아이디어가 떠오를 수 있으니 재작성 해보자
- Outside in TDD
- 인수테스트(ATDD)를 먼저 작성한 뒤 세부 사항(단위 테스트) 작성하기
- 인수테스트를 통해 시나리오 및 전반적인 기능을 이해하고
- 도메인 설계를 진행하며 도메인 객체에 대한 TDD 진행
- 추천하는 흐름
- Top-Down으로 방향을 잡고, Bottom-Up으로 구현하기
- 인수 테스트 작성을 통해 요구사항과 기능 전반에 대한 이해를 선행
- 내부 구현에 대한 설계 흐름을 구상
- 설계가 끝나면 도메인부터 차근차근 TDD로 기능 구현
- 만약 도메인이 복잡하거나 설계가 어려울 경우 이해하고 있는 부분 먼저 기능 구현
- 인수 테스트의 요청을 처리하는 부분부터 진행할 수 있음
ATDD 도입해보기
성공적인 ATDD 적용을 위해
- 나혼자 ATDD
- 토이 프로젝트로 경험 쌓기
- 간단한 기능부터 적용해보기
- 경험해보면서 상황에 맞는 방법 찾기
- 다함께 ATDD
- ATDD 개발 프로세스 룰 정하기(인수 조건, 포맷 등)
- 팀 회의와 회고를 통한 피드백
- 살아있는 규칙 정하기
- 도입해보기
- 아주 쉽게 시작할 수 있는 부분부터 도입
- 조금씩 상황에 맞게 조정
- 가벼운 프로세스부터 시작, 문제점 발견 시 민첩하게 대응
ATDD 적용 전과 후, 장점과 단점
- Common Understaning
- 다른 포지션의 관점은 물론 업무 프로세스도 간접적으로 익힐 수 있음
- 다른 포지션의 진행 상황에 대한 인지와 이해도가 높아짐
- 인수 조건 정의의 어려움
- 문서를 어떻게 관리해야 할 지에 대한 고민이 필요
- 리소스
- (기획/개발) 두번 작업하는 느낌을 받음
반응형
