kth990303의 코딩 블로그

간혹 통합테스트를 작성하다보면 아래와 같은 생각이 들곤 한다. "비즈니스 로직이 의도한대로 작동되는지 테스트는 할 수 있겠어. 하지만 로직 외에 아키텍처 의존성을 테스트할 수는 없을까?" Archunit 라이브러리를 이용하면 아키텍처 의존성, 클래스명 등을 테스트할 수 있다! 참고로 Archunit Guide는 아래 링크에서 확인할 수 있다. https://www.archunit.org/userguide/html/000_Index.html#_introduction ArchUnit User Guide ArchUnit is a free, simple and extensible library for checking the architecture of your Java code. That is, ArchUnit..

해당 글에서는 nGrinder를 이용한 성능테스트 방법에 대해 다룹니다. 사이드 프로젝트 `모카콩`의 Wiki에 작성한 글에 해당된다. 해당 프로젝트 github: https://github.com/mocacong/Mocacong-Backend GitHub - mocacong/Mocacong-Backend: 모카콩 백엔드 모카콩 백엔드. Contribute to mocacong/Mocacong-Backend development by creating an account on GitHub. github.com 들어가며 대부분의 웹 또는 앱 애플리케이션에서는 성능을 위해 페이지네이션을 적용하고 있습니다. 실제로 데이터가 매우 적지 않은 이상, 페이지네이션은 성능 상 유의미한 지표를 가져옵니다. 그렇다면 과연..

코틀린 프로젝트에서 kotest로 테스트 코드를 짜다가 통과해야 할 테스트가 통과하지 않는 현상을 마주치게 됐다. 우리는 StringSpec과 유사한, 중첩되지 않은 구조에서 Given - When - Then 구조의 BehaviorSpec 스타일로 테스트를 마이그레이션하고 있었다. 위 두 테스트 코드는 아예 동일하다. 그저 계층만 나뉘게 바뀌었을 뿐. 구조에 따라 계층을 나누기만 하고, 순서 변경이라든지 코드의 변경이 없었으니 테스트는 당연히 문제 없이 통과할 줄 알았다. 그런데 결과는? Tests Failed... 당연히 WAITING에서 PASS로 변경될 줄 알았는데 Given에서 진행해준 update가 진행되지 않고 WAITING인 상태로 테스트가 진행됐다. 심지어 코드 변경은 전혀 없고 구조에 ..

우리는 @SpringBootTest 어노테이션을 이용하여 손쉽게 통합테스트를 진행할 수 있다. 하지만 @SpringBootTest의 webEnvironment 설정에 따라 테스트 격리가 잘 되지 않는 현상을 발견할 수 있다. 왜 그런 것일까? @SpringBootTest의 webEnvironment @SpringBootTest를 파고 들어가면 아래와 같이 webEnvironment 세팅을 볼 수 있다. 기본값은 MOCK이다. WebApplicationContext를 로드하지만, 내장된 서블릿 컨테이너가 아닌 MOCK 서블릿을 제공한다. 실제 서블릿 환경에서 테스트를 진행해보고 싶다면 RANDOM_PORT나 DEFINED_PORT로 진행해주어야 한다. RANDOM_PORT랑 DEFINED_PORT는 위 사..

Spring Boot 환경에서 여러 협력 객체들이 존재하는 통합테스트는 빈을 호출하기 위해 @SpringBootTest를 사용하는 경우가 많다. 그리고 협력 객체들이 많을 때에는 테스트를 위한 기대 행위 전처리 작업을 mockito를 이용하여 stub을 통해 test double을 만들어주는 경우들이 존재한다. @SpringBootTest와 함께 사용한다면 @Mock, @InjectMocks 대신 @MockBean을 주로 사용할 것이다. 그런데 테스트 코드를 작성하는 방법에 대해 공부하던 도중 @SpyBean이라는 어노테이션을 알게 됐다. 이 어노테이션은 뭐하는 애일까? 그리고 어떻게 사용하는게 좋을까? @MockBean 개인적으로 나는 웬만해선 @MockBean 대신 실제 객체를 사용하는 방식을 사용하..

아래의 테스트 코드를 한 번 보자. 빈 문자열 또는 null일 경우 0을 반환해주게 하는 테스트 코드이다. 또 다른 테스트 코드도 한 번 보자. 방금 보여준 두 개의 테스트 코드는 모두 어딘가에 하자(?)가 존재한다. 바로바로... 하나의 테스트 메소드에 불필요하게 너무 많은 assert문이 존재한다는 것이다! 이러한 경우는 보통, 검증을 제대로 못했거나, 하나의 메소드에 하나의 test라고 생각했지만 여러 개의 test를 묶어놓은 경우이다. 우리는 위 코드들을 알아보기 쉽게 리팩토링해볼 것이다. 1. @ParameterizedTest 이용 먼저 맨 처음 테스트코드 먼저 고쳐보자. 사실 리뷰어(이하 미르)의 피드백을 받기 전까진 @ParameterizedTest가 무엇인지도 몰랐다. @Parameteri..