테스트 코드 정리
1. SSR에서 테스트 코드 의미 있나?
REST API(CSR) 방식과 비교하면 가성비가 떨어지는 건 사실이다.
| 구분 | REST API (CSR) | SSR (Thymeleaf) |
|---|---|---|
| 응답 데이터 | JSON (구조화된 데이터) | HTML (거대한 문자열) |
| 검증 편의성 | 특정 필드 값만 딱 집어서 확인 가능 | HTML 태그 안을 찾아야 함 |
| 검증 대상 | 데이터 정확성, HTTP 상태 코드 | Model 객체, 뷰 이름, 렌더링 텍스트 |
2. SSR 테스트가 불편한 이유
- JSON은
$.name == 'James'처럼 명확하게 검증 가능 - SSR은
body().string(containsString("James"))→ HTML 문자열 검색 - 디자인이 바뀌어 태그 구조만 변경돼도 테스트가 깨질 수 있음
- 서버 테스트인데 HTML/CSS/JS가 섞여 있어 순수 비즈니스 로직 검증이 번거로움
3. SSR에서 테스트한다면 무엇을 검증하나?
HTML 내용 전체를 뜯어보는 테스트는 가성비가 낮다.
대신 아래 3가지만 확인하는 것이 효율적이다.
| 검증 대상 | 설명 |
|---|---|
| View Name | 정확히 community/list.html 로 보내주는가? |
| Model Attributes | 화면에 그려줄 데이터가 Model에 제대로 담겼는가? ← 가장 중요 |
| Redirection | 로그인 성공 후 메인 페이지로 리다이렉트 되는가? |
// SSR 방식의 전형적인 MockMvc 테스트
mockMvc.perform(get("/community/1"))
.andExpect(status().isOk())
.andExpect(view().name("community/detail")) // 뷰 이름 확인
.andExpect(model().attributeExists("community")) // 데이터 담겼는지 확인
.andExpect(model().attributeExists("comments")); // 댓글 담겼는지 확인
4. 실무에서 쓰는 전략
| 계층 | REST API | SSR |
|---|---|---|
| Service / Repository | 단위 테스트 빡빡하게 | 단위 테스트 빡빡하게 (동일) |
| Controller | JSON 응답값 검증 위주로 꼼꼼하게 | 중요한 리다이렉션, Model 데이터 정도만 가볍게 |
핵심: Service/Repository 단위 테스트를 잘 짜두면
“데이터는 문제없다” 를 확신하고 화면(HTML) 수정에만 집중할 수 있다.
5. 결론
- SSR에서 HTML 응답 전체를 검증하는 테스트 → 가성비 낮음, 굳이 X
-
Controller가 Model에 데이터를 제대로 담는지 → 가볍게 확인
- CSR에서는 API별 응답이 잘 오면 전체로직이 잘 돌아간다고 확신할 수 있음. 그래서 테스트코드 굳(통합테스트). 결국엔 SSR은 테스트코드 굳이??