서론
카페 키오스크 개발 당시,
MockMvc 테스트 도구를 활용하여 애플리케이션 서버에 배포하지 않고도
스프링 mvc의 동작을 재현하며 테스트를 수행할 수 있었다.
MockMvc 리팩토링 과정에서 Rest-Assured라는 테스트 도구를 알게 되었고,
이번 포스팅은 두 가지를 비교하면서 Rest-Assured에 대해 자세히 정리해보려고 한다.
Rest-Assured 등장배경
기존의 테스트 프레임워크들은 API 테스트를 작성하는 것에 있어서
RESTful API의 HTTP 요청 및 응답을 쉽게 작성하고 검증하는 것이 어려웠다.
REST-Assured는 간편하게 HTTP 요청을 작성하고 응답을 검증하는 기능을 제공하여
API 테스트를 효율적으로 작성할 수 있도록 도와준다.
또한 단위 테스트, 통합 테스트로 개발자의 안심을 이끌어 낼 수 있지만, 이는 내부 개발자의 관점이다.
Rest-Assured는 외부 사용자의 관점에서 코드에 상관없이 요청과 응답으로 REST API 자동화 테스트를 구성하고 확인할 수 있어서, 사용자의 관점에서 한번 더 안심할 수 있다.
MockMvc vs RestAssured
MockMvc와 RestAssured는 애플리케이션 개발을 할 때 유용한 테스트 도구지만
상황에 맞게 적절한 테스트 도구를 활용할 수 있도록 차이점을 정리해보려고한다.
MockMvc | RestAssured | |
사용 목적 | 1) 웹 애플리케이션을 애플리케이션 서버에 배포하지 않고 스프링 MVC 동작을 재현할 수 있는 라이브러리. 2) 대부분 단위 테스트에 사용 3) 실제 서버 환경과 동일한 @SpringBootTest를 사용할 필요가 없다. 4) @WebMvcTest를 통해 Presentation Layer의 Bean들만 불러오고 그 외의 Bean은 Mock 객체 설정하여 순수한 Controller 로직을 테스트 |
1) REST Web 서비스를 검증하기 위한 라이브러리. 2) 대부분 End-To-End(전 구간 테스트)에 사용 3) @SpringBootTest로 실제 요청을 보내 전체적인 로직을 테스트. 4)실제 요청 시 필요한 다양한 메서드 제공 |
의존성 | Spring Framwork 중 하나로, Spring Test 의존성이 추가되어있는 경우 사용 가능 |
직접 의존성을 추가 (`testImplementation 'io.rest-assured:rest-assured:3.3.0') |
가독성 | 상대적으로 가독성이 좋지 않다. | BDD 스타일(given, when, then) 로 작성되어 가독성이 좋다. |
속도 | @WebMvcTest로 테스트를 수행 (@SpringBootTest도 가능하긴 함) @WebMvcTest는 Presnsentation Layer의 빈만 로드하기 때문에 상대적으로 시간이 빠르다. |
별도의 구성 없이 @WebMvc를 사용하지 못하기 때문에 @SpringBootTest를 실행 (1번 참고) @SpringBootTest는 등록된 스프링 빈을 전부 로드하기 때문에 시간이 오래걸린다. |
속도가 빠른 @WebMvcTest와 별도의 구성이 필요 없는 MockMvc가 항상 유리한 것은 아니다.
Presentation Layer 외의 빈을 여러 개 사용한다면,
전부 Mock 객체로 처리해 주는 비용과 빠른 테스트 시간 중 어느 것을 택할지 생각할 문제이다.
장, 단점
장점
- Given-When-Then 구조를 사용하여 테스트를 작성하므로 읽기 쉽고 이해하기 쉽다.
- 간단한 메서드 체이닝을 통해 HTTP 요청 및 응답을 쉽게 작성하고 검증할 수 있다.
- 응답된 JSON, XML를 손쉽게 검증할 수 있다.
- 블랙박스 테스트로 오로지 Request(요청)와 Response(응답)로 결과를 확인한다.
단점
- 테스트가 많아질수록 코드의 복잡성이 증가
- 테스트 환경을 설정하는 데에 일정한 작업이 필요
Spring 적용 예시
다음은 로그인 요청 관련 토큰 발급 테스트이다.
코드를 살펴보자.
given() 절에서는 어떠한 Http Request를 보내줄지 지정해 주며,
when() 절에서는 이제 어떠한 uri의 api를 호출할 것인지 지정해 준다.
when(). post(uri), when().get(uri), when().put(uri) 등등이 될 수 있다.
then() 절에서는 결과를 리턴해준다.
extract()를 해주면 response를 얻을 수 있고, 여기에는 statusCode (200, 201, 400, 500 등)와 header, jsonpath 등이 존재한다.
given() 절과 then() 절에서 .log().all()를 붙일 경우, 콘솔창에서 http log를 확인해 줄 수 있다.
assertThat으로 200 Created가 잘 보내졌는지, 토큰의 실제 객체 타입이 String으로 잘 변환되는지 확인할 수 있다.
정리
기존에 사용했던 MockMvc 패턴을 RestAssured 라이브러리를 사용하며 BDD 스타일로 변경시키니
가독성 면에서 장점을 가지고 있다는 것을 확인했다.
뿐만 아니라 RestAssured를 다양한 형태로 추출하고 사용되면서 HTTP 요청 및 응답을 쉽게 작성하는 것 같다.
참고자료
[[Spring][TDD] RestAssured를 이용한 e2e test로 Controller API까지 통합 테스트해보자]
'Back-End > Spring' 카테고리의 다른 글
[Spring] Security 테스트 적용기 01 (0) | 2023.10.14 |
---|---|
[Exception] Custom Exception을 언제 써야할까? (0) | 2023.09.18 |
[JPA] QueryDSL을 RepositoryImpl로 관리해보자. (0) | 2023.08.05 |
[MVC] DTO 역할 구분, 프로젝트 흐름도 분석 (0) | 2023.05.09 |
[JPA] Entity를 Dto로 변환(리턴)의 중요성 (0) | 2023.05.08 |