조용한 개발 노트

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

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

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