[테스트] E2E 통합 테스트 확장 (가입→로그인→건강기록→알림)

[RosieOh]

🧑‍💻 오늘의 개발하면서 생긴 크고 작은 이슈사항을 기록해주세요

💚 어떤 기능인가요?

[ Test ] 핵심 사용자 여정(가입→로그인→건강기록→알림)을 Testcontainers 기반 통합 테스트로 자동화합니다.
MariaDB/Redis를 실제 컨테이너로 구동해 운영 환경과 유사한 회귀 검증을 확보합니다.

✅ To Dos

• 시나리오 테스트 클래스 구조 설계
• Testcontainers(MariaDB, Redis) 공통 설정 정리
• 회원가입/로그인/토큰 갱신/로그아웃 흐름 검증
• 건강기록 CRUD + 소유권 검증 시나리오 추가
• 알림 생성/조회/읽음/카운트 시나리오 추가
• 실패 케이스(권한 없음/잘못된 토큰) 검증
• CI에서 재현 가능하도록 안정화

[RosieOh]

남겨 둡니다. 가치 있는 작업이지만 지금 우선순위는 아니라고 판단했습니다.

현재 회귀 방지는 계층별로 이렇게 갖춰져 있습니다 (회귀 방지).

계층	무엇을 잡는가
단위 (Mockito)	알림 판단, 지원금 계산, 예측·통계, 소유권
통합 H2	컨텍스트 로딩, 접근제어 계약 23케이스
Testcontainers	Flyway 스키마와 엔티티 정합성
실연동	공공데이터 4종 (수동)

이 프로젝트에서 실제로 놓쳤던 회귀는 기능 로직이 아니라 스키마 어긋남과 접근제어 뒤집힘이었고, 그 둘은 위 두 테스트가 잡습니다.

E2E 여정 테스트가 추가로 잡을 수 있는 것은 도메인 경계를 넘는 상태 전파입니다. 예를 들어 "건강기록을 만들면 알림 설정이 없는 사용자에게 어떤 채널로 나가는가" 같은 것 — 실제로 #76 에서 이 계열의 버그 4건이 나왔습니다. 그러니 언젠가는 필요합니다.

다만 지금 만들면 유지비가 큽니다. 가입·로그인·자녀 등록·동의·건강기록·알림까지 여섯 단계를 엮어야 하고, 그 중 하나만 바뀌어도 테스트가 깨집니다. 먼저 API 계약이 안정되는 편이 낫고, 특히 #44(API 버전 정책)가 정해지기 전에 만들면 경로를 통째로 다시 써야 합니다.

#44 결정 이후에 착수하는 것을 제안합니다.