[스프링 로드맵] F-1. 테스트란

스프링 프로젝트를 처음 만들면 보통 이런 흐름이다.

• API 만들고
• Swagger로 요청 보내보고
• Postman에서 정상 응답 나오면

그런데 프로젝트 규모가 조금만 커지거나, “이 코드를 남에게 보여줘야 하는 순간”부터 문제가 생긴다.

이 글에서는 Spring에서 테스트가 왜 필요한지 어떤 테스트들이 있고 어디까지 하면 충분한지를 정리한다.

---

1. Swagger만으로는 왜 부족한가?

Swagger는 테스트 도구가 아니라 문서 + 수동 검증 도구다.

Swagger로는 다음까지만 확인 가능하다.

• 요청을 보내면 응답이 오는지
• HTTP 상태 코드가 맞는지
• 대략적인 JSON 구조

하지만 아래는 보장하지 못한다.

• 코드 수정 후 기존 기능이 깨지지 않았는지
• 검증(@Valid)이 정확히 동작하는지
• 예외 상황에서 서비스 로직이 호출되지 않았는지
• DB 트랜잭션이 안전하게 동작하는지

Swagger = 지금 당장 동작 확인

Test = 미래의 변경까지 포함한 안전장치

---

2. 테스트를 하는 이유

보통 이런 상황이 반복된다.

• 기존 코드 수정
• 기능 하나 추가
• 버그 하나 수정

이때마다 매번 Swagger로 모든 API를 다시 눌러볼 수는 없다.

이런 작업이 쌓이다 보면, 변경한 코드 때문에 기존 기능이 영향을 받지 않았는지를 매번 직접 확인하기가 점점 부담이 된다.

그래서 이 코드가 바뀌어도 기존 기능이 깨지지 않는다는 증거로 테스트를 해야한다.

특히 의미있는 건

• 테스트를 많이 작성하는 것 ❌
• 테스트를 의미 있게 선택하는 것 ⭕

---

3. Spring 테스트 종류 한 번에 정리

Spring에서 자주 나오는 테스트들을 간단히 정리하면 아래와 같다.

1) Unit Test

• 특정 클래스/메서드 단위 테스트
• Mockito 위주
• 순수 로직 검증용

👉 선택사항

2) WebMvcTest

• Controller 계층 테스트
• MockMvc 사용
• 요청 / 검증 / 응답 코드 확인

👉 필수에 가까움

3) SpringBootTest

• 스프링 컨텍스트 전체 로딩
• Service + Repository + DB 연동
• 통합 테스트

👉 “이 프로젝트는 실제로 돌아간다”는 증명

4) DataJpaTest

• Repository(JPA) 전용 테스트
• 쿼리 검증에 특화

👉 포트폴리오 가성비는 낮음

5) E2E 테스트

• 실제 서버 띄우고 전체 흐름 테스트
• 비용 높음

👉 초보 단계에서는 과하다고함

---

4. 내가 선택한 테스트

테스트도 코드고, 유지보수 비용이다. 모든 테스트를 다 만드는 건 오히려 비효율이다.

 

✅ WebMvcTest 1개

• 컨트롤러 요청/검증/응답 확인
• 잘못된 요청에서 서비스가 호출되지 않는지 검증

👉 HTTP 계층 안정성 확보

 

✅ SpringBootTest 1개

• H2 DB 사용
• 실제 서비스 로직 + 트랜잭션 검증
• @Transactional로 롤백

👉 비즈니스 로직 신뢰성 확보

 

❌ DataJpaTest 제외

• Repository 테스트는 Service 테스트에 포함됨
• 테스트 중복 대비 효율 낮음

👉 포트폴리오 가성비 관점에서 제외

 

출처:

https://docs.spring.io/spring-framework/reference/testing.html

https://www.baeldung.com/spring-boot-testing