조용한 개발 노트

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)를 기반으로 진행한 1~9편 내용을 하나의 판단 프레임으로 정리한 마무리 편입니다.Spring 테스트의 핵심은 “많이 작성하는 것”이 아니라 적절한 테스트를, 적절한 위치에 배치하는 것입니다. 이 글의 목적은 그 기준을 명확히 하는 것입니다.들어가며지금까지 이 시리즈에서는 반복해서 같은 질문을 던졌습니다.이 테스트는 무엇을 보장하는가?이 검증은 어디까지 필요한가?테스트 실패 시 원인을 바로 좁힐 수 있는가?10편에서는 이 질문들을 한 번에 판단할 수 있는 지도로 정리합니다.1. 테스트 타입 선택의 기본 원칙Spring 테스트 전략의 출발점은 단순합니다.검증하고 싶은 범위만 로딩한다이를 기준으로 테스트 타입을 나누면 ..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)를 기반으로, 실무에서 반복적으로 등장하고, 결국 테스트 신뢰도를 무너뜨렸던 테스트 안티 패턴들을 설계 관점에서 정리합니다.이 안티 패턴들의 공통점은 하나입니다. 처음에는 합리적으로 보였다는 것입니다.안티 패턴 1. 모든 테스트를 @SpringBootTest로 시작하는 경우Spring 테스트를 처음 도입할 때 가장 흔한 선택입니다.설정 고민이 없다실제 환경과 가장 비슷해 보인다하지만 이 선택의 결과는 보통 다음과 같습니다.테스트 실행 시간이 급격히 증가실패 원인을 좁히기 어려움Context 캐싱이 쉽게 깨짐@SpringBootTest는 기본값이 아니라 최후의 선택이다안티 패턴 2. 테스트 목적이 섞인 경우하나의 테스..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)와 Reactor 공식 문서를 기반으로, 비동기 및 Reactive 환경에서 테스트가 왜 어려운지, 그리고 어떻게 접근해야 하는지를 설계 관점에서 정리합니다.비동기 테스트는 기술 문제가 아니라 실행 모델을 이해하는 문제입니다.들어가며동기 코드 테스트에 익숙한 상태에서 Reactive 코드를 처음 테스트하면 다음과 같은 혼란을 겪게 됩니다.테스트가 끝났는데 로직은 아직 실행 중이다예외가 발생했는데 테스트는 통과한다SecurityContext가 사라진다이 문제들은 우연이 아닙니다. 비동기 테스트는 완전히 다른 사고 방식을 요구합니다.1. 비동기 테스트가 어려운 근본적인 이유동기 코드 테스트의 전제는 단순합니다.메서드가 ..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)와 Mockito의 기본 개념을 바탕으로, 테스트에서 자주 사용하는 Mock, Stub, Spy의 차이와 @MockBean / @SpyBean을 언제 어떻게 사용해야 하는지를 설계 관점에서 정리합니다.Mocking은 테스트를 빠르게 만들 수 있지만, 기준 없이 사용하면 테스트의 신뢰도를 무너뜨리는 가장 빠른 방법이 됩니다.들어가며Spring 테스트를 작성하다 보면 다음과 같은 상황을 쉽게 만나게 됩니다.DB를 안 띄우고 싶어서 Repository를 Mock으로 바꾼다외부 API가 귀찮아서 전부 Mock 처리한다테스트가 깨질까 봐 Stub을 잔뜩 만든다이 선택들이 모두 틀린 것은 아닙니다. 문제는,왜 Mock을 쓰는지..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)를 기반으로, DB가 포함된 테스트를 언제 작성해야 하고, 어떻게 설계해야 하는지를 트랜잭션과 격리 관점에서 정리합니다.DB 테스트는 신뢰도를 크게 높여주지만, 잘못 설계하면 테스트 속도와 안정성을 동시에 무너뜨립니다.들어가며DB 테스트를 도입할 때 가장 흔한 고민은 이것입니다.H2 같은 Embedded DB로 충분할까?실제 DB와 완전히 동일해야 할까?모든 Repository 테스트가 필요한가?이 질문에 대한 답은 하나가 아닙니다. DB 테스트 역시 검증 목적에 따라 전략이 달라져야 합니다.1. DB 테스트의 목적부터 분리하자DB가 포함된 테스트는 다음 세 가지 목적 중 하나를 가집니다.쿼리와 매핑 검증트랜잭션 동..

이 글은 Spring Security 공식 문서(Test)와 Spring Test 공식 문서를 기반으로, Spring Security가 적용된 애플리케이션을 테스트 코드에서 어떻게 검증해야 하는지를 설계 관점에서 정리합니다.보안 테스트는 “어떻게 통과시키는가”가 아니라, “무엇을 검증해야 하는가”가 핵심입니다.들어가며Spring Security를 붙인 이후, 테스트에서 가장 자주 마주치는 상황은 이것입니다.모든 요청이 401 또는 403으로 실패한다테스트를 위해 보안을 꺼버리고 싶어진다@WithMockUser를 아무 데나 붙이게 된다이 반응은 자연스럽지만, 그대로 따라가면 보안 테스트는 무의미해집니다.1. 보안 테스트의 목적부터 다시 정의하자보안 테스트에서 가장 먼저 정리해야 할 질문은 이것입니다.이 테..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)를 기반으로, Spring에서 Web API를 테스트할 때 사용하는 MockMvc, TestRestTemplate, WebTestClient를 비교 설명하는 대신, 언제 어떤 도구를 선택해야 하는지를 설계 기준으로 정리합니다.Web 테스트 도구 선택은 문법 취향의 문제가 아니라 테스트 범위와 신뢰도의 문제입니다.들어가며Spring에서 Web 테스트를 시작하면 가장 먼저 이런 고민에 부딪힙니다.MockMvc로 충분할까?실제 서버를 띄워야 할까?WebTestClient는 언제 쓰는 걸까?이 질문에 대한 답은무엇을 검증하려는가?에 따라 달라집니다.1. MockMvc - 컨트롤러 레이어를 빠르게 검증하기MockMvc는서버를..

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)를 기반으로, Spring 테스트에서 가장 중요한 설계 질문인 “이 테스트에서 무엇을 어디까지 로딩해야 하는가”에 답합니다.테스트가 느려지고 복잡해지는 이유의 대부분은, 이 질문에 대한 기준이 없기 때문입니다.들어가며Spring 테스트를 작성하다 보면 다음 두 선택지 앞에 서게 됩니다.간단하니까 @SpringBootTest로 한 번에 끝내자Context 없이 빠르게 테스트하고 싶다이 선택은 단순 취향 문제가 아니라, 테스트 설계 문제입니다.1. Unit Test - Spring 없이 테스트하기Unit Test의 핵심은 명확합니다.하나의 클래스, 하나의 책임만 검증한다이 테스트는Spring Context를 띄우지 않고..

이 글은 Spring Framework 공식 문서(Testing)를 기반으로, Spring 테스트의 핵심 인프라인 TestContext Framework가 ApplicationContext를 어떻게 생성하고, 어떻게 재사용하며, 왜 테스트 성능에 결정적인 영향을 미치는지를 정리합니다.1편에서 테스트의 철학과 전략을 다뤘다면, 이번 편은 Spring 테스트가 실제로 어떻게 동작하는지를 이해하는 출발점입니다.들어가며Spring 테스트를 작성하다 보면 이런 현상을 경험하게 됩니다.테스트 하나 추가했을 뿐인데 전체 테스트가 느려졌다같은 설정인데 어떤 테스트는 빠르고, 어떤 테스트는 느리다@SpringBootTest가 왜 이렇게 무거운지 모르겠다이 문제의 대부분은 ApplicationContext의 생성과 재사용..

이 글은 Spring Framework 공식 문서(Testing)를 기반으로, Spring 애플리케이션에서 테스트가 왜 필요한지, 그리고 어떻게 설계되어야 하는지를 철학과 전략 관점에서 정리합니다.이 시리즈의 목적은 테스트 코드를 많이 작성하는 방법이 아니라, 어떤 테스트를, 왜 작성해야 하는지 판단할 수 있는 기준을 세우는 데 있습니다.들어가며테스트에 대한 이야기는 언제나 양극단으로 흐르기 쉽습니다.테스트는 무조건 많을수록 좋다테스트는 느리고 귀찮다실무에서는 테스트할 시간이 없다Spring 공식 문서는 이 논쟁의 중심에서 아주 차분한 전제를 깔고 시작합니다.Testing is a first-class concern in the Spring Framework.즉, 테스트는 부가 기능이 아니라 프레임워크가..