조용한 개발 노트

이 글은 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.즉, 테스트는 부가 기능이 아니라 프레임워크가..

38편에서는 Auto-Configuration이 성능에 미치는 영향을 통해 기본값이 언제 비용이 되는지를 살펴봤다.이번 글에서는 그 연장선에서, 실무에서 가장 당황스러운 상황 중 하나를 다룬다. “테스트는 다 통과하는데, 운영에서는 왜 깨질까?” 이 문제는 우연이 아니라, 테스트 환경과 운영 환경의 전제가 다르기 때문에 반복해서 발생한다.1) 테스트는 항상 “다른 Spring Boot”를 띄운다많은 개발자가 테스트를 이렇게 인식한다. “운영이랑 같은 Spring Boot를 띄우는 거니까 안전하겠지.” 하지만 실제로 테스트에서 띄우는 Spring Boot는 운영과 완전히 동일하지 않다.테스트는 다음을 의도적으로 바꾼다.ProfilePropertySourceAuto-Configuration 적용 범위외부 의..

25편에서는 Spring Boot Test의 전체 설계 철학과 @SpringBootTest vs Slice Test의 책임 경계를 정리했다.이번 글에서는 테스트를 작성하다 보면 반드시 마주치는 질문을 다룬다. “테스트를 위해 설정을 어디까지 바꿔도 괜찮을까?” 이 질문에 대한 기준이 없으면, 테스트는 점점 늘어나지만 구조는 빠르게 망가진다.1) TestConfiguration은 “편의 기능”이 아니다Spring Boot에서 테스트 전용 설정을 추가할 때 가장 먼저 떠올리는 도구가 @TestConfiguration이다.하지만 이 어노테이션은 “아무 설정이나 넣어도 되는 공간”이 아니다. TestConfiguration은 프로덕션 설정을 대체하기 위한 수단이 아니라, 테스트 환경을 설명하기 위한 도구다. 2..

24편에서는 Startup 성능과 Lazy Initialization을 통해 언제 빠르게 시작하는 것이 좋은 선택인지를 다뤘다.이번 글에서는 그 다음 단계, 개발자가 가장 자주 만지고 가장 자주 불평하는 영역, Spring Boot Test를 다룬다.“왜 테스트가 이렇게 느리지?” “@SpringBootTest 말고 뭐가 다른 거야?” 같은 질문에 구조적으로 답할 수 있게 되는 것이 목표다.1) Spring Boot Test의 출발점은 “신뢰 가능한 기본값”이다Spring Boot Test의 기본 철학은 단순하다. “실제 애플리케이션과 최대한 비슷한 환경에서 테스트하자.” 그래서 기본 테스트 어노테이션이 @SpringBootTest다.이는 “가장 무거운 선택”이 아니라, 가장 안전한 출발점이다.테스트가 ..