From 4ac73b2c6cd0fd16cf680fcf2aa20f10438b1548 Mon Sep 17 00:00:00 2001 From: unknown Date: Fri, 28 Aug 2026 19:20:06 +0900 Subject: [PATCH 01/11] =?UTF-8?q?docs:=20E2E=20=ED=85=8C=EC=8A=A4=ED=8A=B8?= =?UTF-8?q?=20=EC=BC=80=EC=9D=B4=EC=8A=A4=20=EB=8F=84=EB=A9=94=EC=9D=B8?= =?UTF-8?q?=EB=B3=84=20=EC=B4=88=EC=95=88=EA=B3=BC=20=EC=9E=91=EC=97=85=20?= =?UTF-8?q?=EC=9B=90=EB=B3=B8=EC=9D=84=20llm-wiki=EC=97=90=20=EB=B3=B4?= =?UTF-8?q?=EC=A1=B4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 10개 도메인(인증, 랜딩페이지, 그룹, 초대, 정산, 채팅, 커뮤니티, 알림, 친구, 마이페이지)의 테스트 케이스 초안 143건을 output에 남긴다. raw에는 두 건의 작업 원본을 함께 보존한다. - CI 속성 삭제와 Test Guide 재작성 배경 - 도메인별 초안 작성 과정, 그리고 검토용으로 위임한 에이전트가 승인 없이 Notion에 push한 사고의 경위와 사후 처리 Co-Authored-By: Claude Opus 5 (1M context) --- .../output/2026-08-14-e2e-tc-draft-auth.md | 831 ++++++++++++++++++ .../output/2026-08-14-e2e-tc-draft-chat.md | 646 ++++++++++++++ .../2026-08-14-e2e-tc-draft-community.md | 569 ++++++++++++ .../output/2026-08-14-e2e-tc-draft-friend.md | 643 ++++++++++++++ .../output/2026-08-14-e2e-tc-draft-group.md | 735 ++++++++++++++++ .../output/2026-08-14-e2e-tc-draft-invite.md | 685 +++++++++++++++ .../output/2026-08-14-e2e-tc-draft-landing.md | 700 +++++++++++++++ .../output/2026-08-14-e2e-tc-draft-mypage.md | 292 ++++++ .../2026-08-14-e2e-tc-draft-notification.md | 691 +++++++++++++++ .../2026-08-14-e2e-tc-draft-settlement.md | 563 ++++++++++++ ...e2e-tc-domain-drafting-and-runaway-push.md | 46 + ...08-14-e2e-test-case-ci-property-removal.md | 36 + 12 files changed, 6437 insertions(+) create mode 100644 llm-wiki/output/2026-08-14-e2e-tc-draft-auth.md create mode 100644 llm-wiki/output/2026-08-14-e2e-tc-draft-chat.md create mode 100644 llm-wiki/output/2026-08-14-e2e-tc-draft-community.md create mode 100644 llm-wiki/output/2026-08-14-e2e-tc-draft-friend.md create mode 100644 llm-wiki/output/2026-08-14-e2e-tc-draft-group.md create mode 100644 llm-wiki/output/2026-08-14-e2e-tc-draft-invite.md create mode 100644 llm-wiki/output/2026-08-14-e2e-tc-draft-landing.md create mode 100644 llm-wiki/output/2026-08-14-e2e-tc-draft-mypage.md create mode 100644 llm-wiki/output/2026-08-14-e2e-tc-draft-notification.md create mode 100644 llm-wiki/output/2026-08-14-e2e-tc-draft-settlement.md create mode 100644 llm-wiki/raw/2026-08-14-e2e-tc-domain-drafting-and-runaway-push.md create mode 100644 llm-wiki/raw/2026-08-14-e2e-test-case-ci-property-removal.md diff --git a/llm-wiki/output/2026-08-14-e2e-tc-draft-auth.md b/llm-wiki/output/2026-08-14-e2e-tc-draft-auth.md new file mode 100644 index 0000000..adc83f8 --- /dev/null +++ b/llm-wiki/output/2026-08-14-e2e-tc-draft-auth.md @@ -0,0 +1,831 @@ +# 인증 도메인 E2E 테스트 케이스 초안 + +## 조사한 코드 +- `src/app/login/page.tsx` +- `src/app/auth/callback/page.tsx` +- `src/hooks/useAuthCallbackFlow.ts` +- `src/lib/auth.ts` +- `src/lib/authRedirect.ts` +- `src/lib/authStorage.ts` +- `src/app/protectRoute.tsx` +- `src/app/terms-agreement/page.tsx` +- `src/hooks/useTermsAgreementPage.ts` +- `src/lib/termsAgreement.ts` +- `src/components/auth/TermsAgreementPageClient.tsx` +- `src/components/auth/LoginRedirectGuard.tsx` +- `src/components/auth/AuthCallbackClient.tsx` +- `src/app/api/auth/delete-account/route.ts` +- `src/stores/useAuthStore.tsx` + +## 확인 필요 사항 +- 로그인, 콜백, 약관 동의 화면에 표시되는 일부 한국어 문자열이 조사한 소스에서 깨져 있어 정확한 문구 검증 기준은 기획 또는 정상 인코딩된 원문 확인이 필요하다. +- `ProtectRoute`는 로컬 저장소의 사용자 값만으로 첫 번째 보호 경로 접근을 판단한다. 만료되거나 위조된 저장 값이 있을 때 어느 화면으로 보내야 하는지는 코드만으로 판단할 수 없다. +- `ProtectRoute`에서 약관 상태 조회가 실패하면 오류를 기록하고 현재 화면을 유지한다. 이 동작이 의도된 실패 처리인지는 확인이 필요하다. +- 약관 동의 저장은 갱신된 행의 존재 여부를 확인하지 않는다. 인증 사용자와 `user` 행이 실행 중에 어긋난 경우의 기대 동작은 확인이 필요하다. +- 회원 탈퇴 뒤 연결된 서비스 데이터가 어느 범위까지 삭제되는지는 조사 범위의 코드만으로 판단할 수 없다. + +## 케이스 목록 + +### AUTH-LOGIN-REDIRECT-001: 로그인한 사용자가 로그인 화면을 열면 홈으로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 로그인 화면 재접근 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +로그인된 사용자가 로그인 화면에 머물지 않고 홈으로 복귀하는지 검증한다. + +## 시나리오 +로그인 사용자 상태가 로컬 저장소에 있는 상태에서 로그인 화면을 연다. + +## Given +- Supabase Admin API로 만든 로그인 세션을 브라우저에 주입한다. +- `user-store` 로컬 저장소에 로그인 사용자가 저장되어 있다. + +## When +- `/login`으로 이동한다. + +## Then +- `/home`으로 경로가 바뀐다. +- 로그인 버튼 화면은 표시되지 않는다. + +## 테스트 데이터 +- 필수 약관에 동의한 로그인 사용자 1명 + +## 데이터 준비 방식 상세 +- 사용자와 세션을 API Helper로 만들고 세션 및 `user-store` 값을 브라우저 문맥에 주입한다. + +## Cleanup 대상 +- 생성한 인증 사용자와 `user` 행 +- 브라우저 세션 및 로컬 저장소 + +## 예외/주의사항 +- 이 케이스는 외부 소셜 로그인 제공자 화면을 열지 않는다. + +--- + +### AUTH-LOGIN-REDIRECT-002: 허용되지 않은 로그인 복귀 경로는 홈으로 바뀐다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 로그인 복귀 경로 검증 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | UI 조작 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +로그인 요청에 외부 주소나 허용 목록 밖의 내부 경로가 들어와도 안전한 기본 경로만 콜백에 전달되는지 검증한다. + +## 시나리오 +허용되지 않은 `redirect` 값을 가진 로그인 화면에서 소셜 로그인 버튼을 누른다. + +## Given +- 로그인 세션이 없다. +- `/login?redirect=https%3A%2F%2Fevil.example`로 이동해 로그인 화면이 보인다. +- OAuth 요청은 브라우저에서 가로채 외부 제공자 화면으로 이동하지 않게 한다. + +## When +- 소셜 로그인 버튼 하나를 누른다. + +## Then +- Supabase OAuth 호출의 `redirectTo`에 포함된 콜백의 `next` 값이 `/home`이다. +- 외부 주소가 복귀 경로에 포함되지 않는다. + +## 테스트 데이터 +- 외부 주소 형태의 `redirect` 값 + +## 데이터 준비 방식 상세 +- 로그인 화면을 열고 OAuth 호출을 가로채 전달된 선택 사항을 검사한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 실제 구글 또는 카카오 로그인 화면은 검증하지 않는다. + +--- + +### AUTH-CALLBACK-001: 약관에 동의한 사용자는 인증 콜백 뒤 요청한 초대 경로로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 로그인 콜백 처리 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +인증 사용자와 사용자 행이 있고 필수 약관에 동의한 경우 원래 요청한 초대 흐름으로 복귀하는지 검증한다. + +## 시나리오 +로그인 세션을 주입한 사용자가 초대 경로를 가진 인증 콜백을 연다. + +## Given +- 인증 사용자와 같은 식별자의 `user` 행이 있다. +- `terms_agreed`와 `privacy_agreed`가 모두 참이다. +- 해당 사용자의 세션을 브라우저에 주입한다. + +## When +- `/auth/callback?next=%2Finvite%2Fsample-code`로 이동한다. + +## Then +- 사용자 저장소에 인증 사용자 정보가 저장된다. +- `/invite/sample-code`로 경로가 바뀐다. + +## 테스트 데이터 +- 필수 약관에 동의한 사용자 1명 +- 초대 코드 `sample-code` + +## 데이터 준비 방식 상세 +- Supabase Admin API와 Seed로 인증 사용자, `user` 행, 로그인 세션을 준비한다. + +## Cleanup 대상 +- 생성한 인증 사용자와 `user` 행 +- 브라우저 세션 및 로컬 저장소 + +## 예외/주의사항 +- 초대 코드 자체의 유효성은 이 케이스 범위가 아니다. + +--- + +### AUTH-CALLBACK-002: 약관에 동의하지 않은 사용자는 인증 콜백 뒤 약관 동의 화면으로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 로그인 콜백 처리 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +필수 약관 동의가 끝나지 않은 로그인 사용자를 약관 동의 흐름으로 보내고 원래 복귀 경로를 보존하는지 검증한다. + +## 시나리오 +약관 미동의 사용자가 초대 경로를 가진 인증 콜백을 연다. + +## Given +- 인증 사용자와 같은 식별자의 `user` 행이 있다. +- 필수 약관 동의 값 가운데 하나 이상이 거짓이다. +- 해당 사용자의 세션을 브라우저에 주입한다. + +## When +- `/auth/callback?next=%2Finvite%2Fsample-code`로 이동한다. + +## Then +- 사용자 저장소에 인증 사용자 정보가 저장된다. +- `/terms-agreement?next=%2Finvite%2Fsample-code`로 경로가 바뀐다. + +## 테스트 데이터 +- 필수 약관에 동의하지 않은 사용자 1명 +- 초대 코드 `sample-code` + +## 데이터 준비 방식 상세 +- Supabase Admin API와 Seed로 사용자, 미동의 상태의 `user` 행, 세션을 준비한다. + +## Cleanup 대상 +- 생성한 인증 사용자와 `user` 행 +- 브라우저 세션 및 로컬 저장소 + +## 예외/주의사항 +- 약관 두 항목 중 어느 하나만 거짓이어도 같은 분기로 이동한다. + +--- + +### AUTH-CALLBACK-003: 인증 세션이 없는 콜백 화면은 오류 메시지를 표시한다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 로그인 콜백 처리 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +인증 콜백에서 사용자를 얻지 못했을 때 무한 로딩 대신 오류 상태를 보여 주는지 검증한다. + +## 시나리오 +세션이 없는 사용자가 인증 콜백 주소를 직접 연다. + +## Given +- 브라우저에 Supabase 로그인 세션이 없다. + +## When +- `/auth/callback`으로 이동한다. + +## Then +- 인증 사용자 정보를 찾지 못했다는 오류 메시지 영역이 표시된다. +- 로딩 표시가 끝난다. +- 홈이나 약관 동의 화면으로 이동하지 않는다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- 새 브라우저 문맥에서 세션 없이 시작한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 정확한 한국어 오류 문구는 소스 인코딩 확인 뒤 고정한다. + +--- + +### AUTH-CALLBACK-004: 사용자 행이 없는 인증 사용자의 콜백은 오류 메시지를 표시한다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 로그인 콜백 처리 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +인증 사용자는 있지만 대응하는 서비스 사용자 행이 끝내 생성되지 않은 경우 오류 상태를 보여 주는지 검증한다. + +## 시나리오 +`user` 행이 없는 인증 사용자가 콜백을 연다. + +## Given +- 인증 사용자는 존재한다. +- 같은 식별자의 `user` 행은 없다. +- 해당 사용자의 세션을 브라우저에 주입한다. + +## When +- `/auth/callback`으로 이동한다. + +## Then +- 사용자 정보를 찾지 못했다는 오류 메시지 영역이 표시된다. +- 홈이나 약관 동의 화면으로 이동하지 않는다. + +## 테스트 데이터 +- `user` 행이 없는 인증 사용자 1명 + +## 데이터 준비 방식 상세 +- Supabase Admin API로 인증 사용자와 세션만 만들고 `user` 행은 만들지 않는다. + +## Cleanup 대상 +- 생성한 인증 사용자 +- 브라우저 세션 + +## 예외/주의사항 +- 코드에는 사용자 행 조회를 처음 조회 포함 최대 세 번 수행하는 재시도 로직이 있어 완료까지 약간 지연될 수 있다. + +--- + +### AUTH-CALLBACK-005: 콜백의 외부 복귀 주소는 홈 경로로 바뀐다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 콜백 복귀 경로 검증 | +| 케이스 유형 | 회귀 | +| 우선순위 | P0 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +인증 콜백을 이용한 외부 주소 이동을 막는지 검증한다. + +## 시나리오 +약관 동의 사용자가 외부 주소를 `next`로 넣은 콜백을 연다. + +## Given +- 필수 약관에 동의한 사용자의 세션이 주입되어 있다. +- 인증 사용자와 `user` 행이 모두 있다. + +## When +- `/auth/callback?next=https%3A%2F%2Fevil.example`로 이동한다. + +## Then +- `/home`으로 경로가 바뀐다. +- 외부 주소로 이동하지 않는다. + +## 테스트 데이터 +- 필수 약관에 동의한 사용자 1명 +- 외부 주소 형태의 `next` 값 + +## 데이터 준비 방식 상세 +- 사용자와 세션을 준비하고 콜백 주소의 질의 값만 외부 주소로 지정한다. + +## Cleanup 대상 +- 생성한 인증 사용자와 `user` 행 +- 브라우저 세션 및 로컬 저장소 + +## 예외/주의사항 +- 이 검증은 `//`로 시작하는 주소와 역슬래시가 든 주소에도 같은 원칙이 적용된다. + +--- + +### AUTH-PROTECT-001: 비로그인 사용자가 보호 경로를 열면 첫 화면으로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 보호 경로 접근 제어 | +| 케이스 유형 | 권한 | +| 우선순위 | P0 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +저장된 로그인 사용자 없이 보호 경로의 내용을 볼 수 없는지 검증한다. + +## 시나리오 +비로그인 사용자가 홈 경로를 직접 연다. + +## Given +- 브라우저의 `user-store` 로컬 저장소가 비어 있다. +- 로그인 세션이 없다. + +## When +- `/home`으로 이동한다. + +## Then +- `/`로 경로가 바뀐다. +- 이동 중 보호 경로의 자식 화면은 표시되지 않는다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- 새 브라우저 문맥에서 시작한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 코드상 초대 경로와 공개 경로는 이 차단에서 제외된다. + +--- + +### AUTH-PROTECT-002: 약관에 동의하지 않은 로그인 사용자가 보호 경로를 열면 약관 동의 화면으로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 약관 기반 접근 제어 | +| 케이스 유형 | 권한 | +| 우선순위 | P0 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +로그인 상태라도 필수 약관에 동의하지 않으면 일반 보호 화면을 이용할 수 없는지 검증한다. + +## 시나리오 +약관 미동의 사용자가 홈 경로를 직접 연다. + +## Given +- 필수 약관 동의 값 가운데 하나 이상이 거짓인 `user` 행이 있다. +- 해당 사용자 세션과 `user-store` 값을 브라우저에 주입한다. + +## When +- `/home`으로 이동한다. + +## Then +- `/terms-agreement`로 경로가 바뀐다. + +## 테스트 데이터 +- 필수 약관에 동의하지 않은 사용자 1명 + +## 데이터 준비 방식 상세 +- Supabase Admin API와 Seed로 사용자 및 미동의 상태를 만들고 세션과 저장소 값을 주입한다. + +## Cleanup 대상 +- 생성한 인증 사용자와 `user` 행 +- 브라우저 세션 및 로컬 저장소 + +## 예외/주의사항 +- 약관 동의 화면, 이용 약관, 개인 정보 처리 방침 등 제외 경로에서는 이 이동이 일어나지 않는다. + +--- + +### AUTH-TERMS-001: 비로그인 사용자가 약관 동의 화면을 열면 로그인 화면으로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 약관 동의 화면 진입 | +| 케이스 유형 | 권한 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +인증되지 않은 사용자가 약관 동의 절차를 수행할 수 없는지 검증한다. + +## 시나리오 +세션이 없는 사용자가 약관 동의 주소를 직접 연다. + +## Given +- 로그인 세션이 없다. + +## When +- `/terms-agreement`로 이동한다. + +## Then +- `/login`으로 경로가 바뀐다. +- 약관 선택 양식은 표시되지 않는다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- 새 브라우저 문맥에서 시작한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 초기 사용자 확인 동안에는 로딩 표시가 나타날 수 있다. + +--- + +### AUTH-TERMS-002: 이미 약관에 동의한 사용자가 약관 동의 화면을 열면 요청한 경로로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 약관 동의 화면 재접근 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +필수 약관 동의가 끝난 사용자가 약관 양식을 다시 제출하지 않고 원래 흐름으로 복귀하는지 검증한다. + +## 시나리오 +약관 동의 사용자가 초대 복귀 경로를 가진 약관 동의 화면을 연다. + +## Given +- 필수 약관에 모두 동의한 사용자와 로그인 세션이 있다. + +## When +- `/terms-agreement?next=%2Finvite%2Fsample-code`로 이동한다. + +## Then +- `/invite/sample-code`로 경로가 바뀐다. +- 약관 선택 양식은 표시되지 않는다. + +## 테스트 데이터 +- 필수 약관에 동의한 사용자 1명 +- 초대 코드 `sample-code` + +## 데이터 준비 방식 상세 +- Supabase Admin API와 Seed로 동의 완료 사용자 및 세션을 준비한다. + +## Cleanup 대상 +- 생성한 인증 사용자와 `user` 행 +- 브라우저 세션 및 로컬 저장소 + +## 예외/주의사항 +- 허용되지 않은 `next`는 `/home`으로 바뀐다. + +--- + +### AUTH-TERMS-003: 필수 약관을 모두 선택한 사용자는 동의를 저장하고 요청한 경로로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 필수 약관 동의 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +두 필수 항목에 동의하면 동의 시각과 버전이 저장되고 원래 경로로 이동하는지 검증한다. + +## 시나리오 +약관 미동의 사용자가 모든 필수 항목을 선택해 제출한다. + +## Given +- 필수 약관에 동의하지 않은 사용자와 로그인 세션이 있다. +- `/terms-agreement?next=%2Finvite%2Fsample-code`를 열어 양식이 표시되어 있다. + +## When +- 이용 약관과 개인 정보 처리 방침을 모두 선택한다. +- 동의 제출 동작을 수행한다. + +## Then +- `user` 행의 `terms_agreed`와 `privacy_agreed`가 모두 참으로 갱신된다. +- 두 동의 시각이 저장된다. +- `terms_version`과 `privacy_version`이 각각 `2026-05-26`으로 저장된다. +- `/invite/sample-code`로 경로가 바뀐다. + +## 테스트 데이터 +- 필수 약관에 동의하지 않은 사용자 1명 +- 초대 코드 `sample-code` + +## 데이터 준비 방식 상세 +- 사용자와 세션은 API Helper와 Seed로 준비하고, 약관 선택과 제출은 UI로 수행한다. + +## Cleanup 대상 +- 생성한 인증 사용자와 `user` 행 +- 브라우저 세션 및 로컬 저장소 + +## 예외/주의사항 +- 저장 중에는 다시 제출되지 않도록 제출 상태가 유지되어야 한다. + +--- + +### AUTH-TERMS-004: 필수 약관을 모두 선택하지 않으면 동의가 제출되지 않는다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 필수 약관 동의 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +필수 항목 일부가 선택되지 않은 상태에서는 동의 저장과 화면 이동이 일어나지 않는지 검증한다. + +## 시나리오 +약관 미동의 사용자가 한 항목만 선택한 상태에서 제출을 시도한다. + +## Given +- 필수 약관에 동의하지 않은 사용자와 로그인 세션이 있다. +- 약관 선택 양식이 표시되어 있다. + +## When +- 두 필수 항목 중 하나만 선택한다. +- 동의 제출 동작을 시도한다. + +## Then +- 현재 약관 동의 화면에 머문다. +- `user` 행의 약관 동의 값과 버전 및 시각이 갱신되지 않는다. + +## 테스트 데이터 +- 필수 약관에 동의하지 않은 사용자 1명 + +## 데이터 준비 방식 상세 +- 사용자와 세션은 API Helper와 Seed로 준비하고 한 항목만 UI에서 선택한다. + +## Cleanup 대상 +- 생성한 인증 사용자와 `user` 행 +- 브라우저 세션 및 로컬 저장소 + +## 예외/주의사항 +- `submitAgreement`는 두 항목이 모두 선택되지 않으면 바로 끝난다. + +--- + +### AUTH-TERMS-005: 약관 동의 저장이 실패하면 오류를 알리고 현재 화면에 머문다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 필수 약관 동의 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +약관 동의 갱신 요청이 실패해도 성공 경로로 이동하지 않고 사용자가 실패를 알 수 있는지 검증한다. + +## 시나리오 +약관 미동의 사용자가 모든 항목을 선택하지만 저장 요청이 실패한다. + +## Given +- 약관 미동의 사용자의 세션이 주입되어 있다. +- 약관 동의 갱신 요청이 오류를 반환하도록 Mock한다. + +## When +- 두 필수 항목을 모두 선택한다. +- 동의 제출 동작을 수행한다. + +## Then +- 약관 동의 저장 실패 알림이 표시된다. +- 현재 약관 동의 화면에 머문다. +- 다시 제출할 수 있도록 제출 중 상태가 해제된다. + +## 테스트 데이터 +- 필수 약관에 동의하지 않은 사용자 1명 +- 약관 갱신 오류 응답 + +## 데이터 준비 방식 상세 +- 로그인 세션을 주입하고 Supabase `user` 갱신 요청만 실패 응답으로 가로챈다. + +## Cleanup 대상 +- 생성한 인증 사용자와 `user` 행 +- 브라우저 세션 및 로컬 저장소 + +## 예외/주의사항 +- 정확한 오류 알림 문구는 소스 인코딩 확인 뒤 고정한다. + +--- + +### AUTH-TERMS-006: 약관 동의를 나중에 하기로 확정하면 로그아웃하고 복귀 경로를 가진 로그인 화면으로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 약관 동의 나중에 하기 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +약관 동의를 중단한 사용자의 인증 및 저장 상태를 지우고 원래 복귀 경로를 보존하는지 검증한다. + +## 시나리오 +약관 미동의 사용자가 나중에 하기를 선택하고 나가기 창에서 확정한다. + +## Given +- 약관 미동의 사용자의 세션과 사용자 저장 값이 주입되어 있다. +- `/terms-agreement?next=%2Finvite%2Fsample-code`의 양식이 표시되어 있다. + +## When +- 나중에 하기 또는 뒤로 가기 동작을 수행한다. +- 열린 나가기 창에서 나가기를 확정한다. + +## Then +- Supabase에서 로그아웃된다. +- 사용자 저장소의 사용자가 비워진다. +- 오래된 세션 저장 값이 제거된다. +- `/login?redirect=%2Finvite%2Fsample-code`로 경로가 바뀐다. + +## 테스트 데이터 +- 필수 약관에 동의하지 않은 사용자 1명 +- 초대 코드 `sample-code` + +## 데이터 준비 방식 상세 +- 사용자와 세션 및 저장소 값을 준비한 뒤 나가기 동작은 UI로 수행한다. + +## Cleanup 대상 +- 생성한 인증 사용자와 `user` 행 +- 브라우저 저장소 + +## 예외/주의사항 +- 나가기 창을 닫는 동작은 로그아웃하지 않고 약관 화면을 유지해야 한다. + +--- + +### AUTH-DELETE-001: 인증 토큰 없이 회원 탈퇴를 요청하면 거부된다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 회원 탈퇴 인증 검사 | +| 케이스 유형 | 권한 | +| 우선순위 | P0 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 권한 없음 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +인증 토큰이 없는 요청으로 회원을 탈퇴시킬 수 없는지 검증한다. + +## 시나리오 +인증 헤더 없이 회원 탈퇴 끝점을 호출한다. + +## Given +- `Authorization` 헤더를 준비하지 않는다. + +## When +- `POST /api/auth/delete-account`를 호출한다. + +## Then +- 응답 상태가 401이다. +- 인증 토큰이 없다는 메시지가 응답에 포함된다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- Playwright의 요청 문맥으로 인증 헤더 없이 직접 호출한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 서버의 Supabase 환경 변수가 정상 설정된 시험 환경에서 실행해야 401 분기를 검증할 수 있다. + +--- + +### AUTH-DELETE-002: 유효하지 않은 인증 토큰으로 회원 탈퇴를 요청하면 거부된다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 회원 탈퇴 인증 검사 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 권한 없음 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +Bearer 형식이더라도 유효하지 않은 토큰으로 회원을 탈퇴시킬 수 없는지 검증한다. + +## 시나리오 +유효하지 않은 Bearer 토큰으로 회원 탈퇴 끝점을 호출한다. + +## Given +- 유효하지 않은 문자열 토큰을 준비한다. + +## When +- 해당 토큰을 `Authorization: Bearer` 헤더에 넣어 `POST /api/auth/delete-account`를 호출한다. + +## Then +- 응답 상태가 401이다. +- 유효하지 않은 인증 토큰이라는 메시지가 응답에 포함된다. + +## 테스트 데이터 +- 유효하지 않은 접근 토큰 문자열 + +## 데이터 준비 방식 상세 +- Playwright의 요청 문맥으로 잘못된 Bearer 토큰을 보내 직접 호출한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 서버의 Supabase 환경 변수가 정상 설정된 시험 환경에서 실행한다. + +--- + +### AUTH-DELETE-003: 로그인 사용자가 회원 탈퇴를 완료하면 인증 사용자와 로컬 로그인 상태가 제거된다 +| 속성 | 값 | +|---|---| +| 도메인 | 인증 | +| 시나리오 | 회원 탈퇴 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 확인 필요 | +| 관련 Issue | | + +## 목적 +유효한 로그인 사용자의 탈퇴 요청이 관리자 삭제까지 완료되고 브라우저의 로그인 상태도 정리되는지 검증한다. + +## 시나리오 +로그인 사용자가 서비스의 회원 탈퇴 동작을 수행한다. + +## Given +- 삭제 전용 인증 사용자와 `user` 행을 준비한다. +- 해당 사용자 세션과 사용자 저장 값을 브라우저에 주입한다. + +## When +- 서비스의 회원 탈퇴 동작을 수행한다. + +## Then +- `POST /api/auth/delete-account`가 성공한다. +- Supabase 인증 사용자 조회 결과에서 대상 사용자가 사라진다. +- 로컬 범위에서 로그아웃된다. +- 사용자 저장소와 오래된 인증 저장 값이 제거된다. +- 잠시 뒤 `/login`으로 경로가 바뀐다. + +## 테스트 데이터 +- 탈퇴 검증 전용 로그인 사용자 1명 + +## 데이터 준비 방식 상세 +- Supabase Admin API로 삭제 가능한 전용 사용자와 세션을 만들고 브라우저에 주입한다. + +## Cleanup 대상 +- 탈퇴가 실패해 남은 인증 사용자와 `user` 행 +- 브라우저 세션 및 저장소 + +## 예외/주의사항 +- 탈퇴가 성공하면 인증 사용자는 이미 삭제되므로 Cleanup은 잔존 여부를 확인한 뒤 조건부로 수행한다. +- 서비스 화면에서 회원 탈퇴를 시작하는 요소는 이번 조사 범위 밖이므로 자동화 구현 전에 진입 경로를 확인해야 한다. + diff --git a/llm-wiki/output/2026-08-14-e2e-tc-draft-chat.md b/llm-wiki/output/2026-08-14-e2e-tc-draft-chat.md new file mode 100644 index 0000000..cfb0202 --- /dev/null +++ b/llm-wiki/output/2026-08-14-e2e-tc-draft-chat.md @@ -0,0 +1,646 @@ +# 채팅 도메인 E2E 테스트 케이스 초안 + +## 조사한 코드 +- `src/components/chat/ChatRoom.tsx` +- `src/components/chat/MessageItem.tsx` +- `src/components/chat/MessageList.tsx` +- `src/lib/chatMessage/getChatMessages.tsx` +- `src/lib/chatMessage/insertChatMessage.tsx` +- `src/types/chatMessage.ts` +- `src/utils/formatChatMessageTime.ts` +- `supabase/functions/chat-notification/index.ts` +- `supabase/functions/chat-notification/deno.json` +- `supabase/functions/chat-notification/.npmrc` + +## 확인 필요 사항 +- `ChatRoom.tsx`, `MessageItem.tsx`, `MessageList.tsx`, `getChatMessages.tsx`, `chat-notification/index.ts`의 일부 한국어 문자열이 깨져 있어 토스트, 입력 안내 문구, 빈 상태, 전송 실패 표시, 푸시 알림 제목과 본문의 정확한 기대 문구를 코드에서 확정할 수 없다. +- 조사 범위에는 채팅 화면을 실제로 노출하는 라우트 파일과 그룹 참여 권한을 검사하는 코드가 포함되지 않아, 비참여자의 채팅방 접근 허용 여부와 진입 주소는 확정할 수 없다. +- `chat-notification`은 `OPTIONS` 요청에서도 본문을 먼저 JSON으로 해석한다. 본문이 없는 실제 사전 요청이 정상 처리되어야 하는지는 기획과 운영 환경 확인이 필요하다. +- 알림 전송 결과 저장 함수는 기다리지 않고 호출하며 저장 실패 처리도 없다. 알림 이력 저장 완료를 응답 전에 보장해야 하는지는 확인이 필요하다. +- 전송 실패 메시지를 다시 보내는 동작이나 실패 메시지를 제거하는 동작은 구현되어 있지 않다. 해당 기능이 필요한지는 확인이 필요하다. + +## 케이스 목록 + +### CHAT-HISTORY-001: 채팅방에 들어가면 저장된 메시지가 생성 시각 순서대로 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 채팅 내역 조회 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +채팅 내역 조회 결과가 데이터베이스 반환 순서와 관계없이 생성 시각 오름차순으로 표시되는지 검증한다. + +## 시나리오 +사용자가 기존 메시지가 있는 채팅방에 들어가 대화 순서를 확인한다. + +## Given +- 로그인 세션을 주입한다. +- 같은 `nbread_id`에 생성 시각이 서로 다른 메시지 3개를 조회 결과와 다른 순서로 준비한다. + +## When +- 해당 채팅방에 진입한다. + +## Then +- 초기 로딩 표시가 끝난다. +- 세 메시지가 `created_at` 오름차순으로 표시된다. +- 각 메시지 시각은 `Asia/Seoul`, 시와 분 형식으로 표시된다. + +## 테스트 데이터 +- 채팅 그룹 1개, 로그인 사용자 1명, 생성 시각이 다른 채팅 메시지 3개 + +## 데이터 준비 방식 상세 +- Seed로 그룹과 메시지를 만들고 Supabase Admin API로 만든 로그인 세션을 브라우저에 주입한다. + +## Cleanup 대상 +- 생성한 채팅 메시지와 그룹 데이터 + +## 예외/주의사항 +- 정확한 시각 문자열은 실행 브라우저의 `ko-KR` 표기 결과를 기준으로 계산한다. + +--- + +### CHAT-HISTORY-002: 메시지가 없는 채팅방에 들어가면 빈 상태가 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 채팅 빈 상태 확인 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +조회가 성공했지만 메시지가 없을 때 빈 상태가 표시되는지 검증한다. + +## 시나리오 +사용자가 아직 대화가 없는 채팅방에 들어간다. + +## Given +- 로그인 세션을 주입한다. +- 채팅 메시지가 없는 그룹을 준비한다. + +## When +- 해당 채팅방에 진입한다. + +## Then +- 초기 로딩 표시가 끝난다. +- 메시지가 없음을 알리는 빈 상태가 표시된다. +- 메시지 입력란은 사용할 수 있다. + +## 테스트 데이터 +- 채팅 메시지가 없는 그룹 1개와 로그인 사용자 1명 + +## 데이터 준비 방식 상세 +- Seed로 빈 그룹을 만들고 로그인 세션을 주입한다. + +## Cleanup 대상 +- 생성한 그룹 데이터 + +## 예외/주의사항 +- 빈 상태의 정확한 문구는 소스 문자열이 깨져 있어 접근 가능한 요소와 화면 노출 여부로 검증하고, 문구 확정 뒤 보강한다. + +--- + +### CHAT-DISPLAY-001: 내 메시지와 다른 사용자의 메시지가 서로 다른 방향으로 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 메시지 발신자 구분 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +현재 사용자 식별자를 기준으로 본인과 상대방 메시지의 배치 및 발신자 정보가 올바르게 구분되는지 검증한다. + +## 시나리오 +사용자가 본인과 다른 참여자가 작성한 메시지를 함께 확인한다. + +## Given +- 사용자 A의 로그인 세션을 주입한다. +- 같은 채팅방에 사용자 A와 사용자 B의 메시지를 각각 준비한다. + +## When +- 사용자 A가 채팅방에 진입한다. + +## Then +- 사용자 A의 메시지는 오른쪽 정렬로 표시된다. +- 사용자 B의 메시지는 왼쪽 정렬로 표시된다. +- 사용자 B의 메시지에는 이름과 프로필 이미지 영역이 표시된다. +- 사용자 A의 메시지에는 발신자 이름과 프로필 이미지 영역이 표시되지 않는다. + +## 테스트 데이터 +- 그룹 1개, 사용자 2명, 각 사용자의 메시지 1개씩 + +## 데이터 준비 방식 상세 +- Seed로 사용자, 그룹, 메시지를 준비하고 사용자 A의 세션을 주입한다. + +## Cleanup 대상 +- 생성한 메시지, 그룹, 테스트 사용자 + +## 예외/주의사항 +- 정렬은 화면 요소의 위치 좌표와 발신자 정보 노출 여부로 검증한다. + +--- + +### CHAT-DISPLAY-002: 같은 사용자의 연속 메시지는 발신자와 시각이 묶여 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 연속 메시지 묶음 표시 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +같은 사용자가 연속해서 보낸 메시지에서 중복 발신자 정보와 중간 시각이 생략되는지 검증한다. + +## 시나리오 +사용자가 상대방이 같은 분에 연속해서 보낸 메시지 묶음을 확인한다. + +## Given +- 사용자 A의 로그인 세션을 주입한다. +- 사용자 B가 같은 표시 시각에 연속으로 작성한 메시지 2개를 준비한다. + +## When +- 사용자 A가 채팅방에 진입한다. + +## Then +- 사용자 B의 이름과 프로필 이미지 영역은 첫 메시지에만 표시된다. +- 첫 메시지에는 시각이 표시되지 않는다. +- 묶음의 마지막 메시지에만 시각이 표시된다. + +## 테스트 데이터 +- 사용자 A와 B, 그룹 1개, 사용자 B의 같은 분 메시지 2개 + +## 데이터 준비 방식 상세 +- Seed에서 두 메시지의 `created_at`을 같은 한국 시각의 시와 분으로 준비하고 사용자 A의 세션을 주입한다. + +## Cleanup 대상 +- 생성한 메시지, 그룹, 테스트 사용자 + +## 예외/주의사항 +- 두 메시지 사이에 다른 사용자 메시지가 있으면 새 묶음이 시작되므로 연속 상태를 유지한다. + +--- + +### CHAT-SEND-001: 내용을 입력하고 엔터를 누르면 메시지가 저장되고 입력란이 비워진다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 메시지 전송 | +| 케이스 유형 | Smoke | +| 우선순위 | P0 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +로그인 사용자의 기본 메시지 전송 흐름이 정상 동작하는지 검증한다. + +## 시나리오 +사용자가 채팅 내용을 입력하고 엔터로 전송한다. + +## Given +- 로그인 세션을 주입한다. +- 접근할 채팅 그룹을 준비하고 채팅방에 진입한다. + +## When +- 입력란에 `안녕하세요`를 입력한다. +- 조합 중이 아닌 상태에서 엔터를 누른다. + +## Then +- 입력 직후 `안녕하세요` 메시지가 화면에 표시된다. +- 입력란 값이 빈 문자열로 바뀐다. +- 저장 성공 뒤 임시 메시지가 실제 저장 메시지로 교체되고 같은 내용이 중복 표시되지 않는다. +- `chat_messages`에 로그인 사용자와 해당 그룹, 입력 내용으로 된 행이 1개 생성된다. + +## 테스트 데이터 +- 로그인 사용자 1명, 그룹 1개, 메시지 내용 `안녕하세요` + +## 데이터 준비 방식 상세 +- Supabase Admin API로 만든 로그인 세션을 주입하고 기존 그룹을 사용한다. + +## Cleanup 대상 +- 테스트 중 생성한 채팅 메시지 + +## 예외/주의사항 +- 저장 응답 전 낙관적 메시지의 매우 짧은 노출은 네트워크 지연을 제어할 수 있을 때만 별도로 확인한다. + +--- + +### CHAT-SEND-002: 빈 문자열이나 공백만 입력하고 엔터를 눌러도 메시지가 전송되지 않는다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 빈 메시지 전송 방지 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +입력값을 다듬었을 때 비어 있는 메시지가 전송되지 않는지 검증한다. + +## 시나리오 +사용자가 내용 없이 또는 공백만 입력한 채 엔터를 누른다. + +## Given +- 로그인 세션을 주입하고 채팅방에 진입한다. +- 테스트 시작 시점의 메시지 수를 기록한다. + +## When +- 빈 입력 상태에서 엔터를 누른다. +- 공백만 입력한 뒤 엔터를 누른다. + +## Then +- 새 메시지가 화면에 추가되지 않는다. +- `chat_messages`에 새 행이 생성되지 않는다. +- 공백 입력값은 그대로 유지된다. + +## 테스트 데이터 +- 로그인 사용자 1명, 그룹 1개, 공백 입력값 + +## 데이터 준비 방식 상세 +- 로그인 세션만 주입하고 전송 전후 데이터베이스 행 수를 API Helper로 비교한다. + +## Cleanup 대상 +- 생성되는 데이터가 없어 불필요하다. + +## 예외/주의사항 +- 현재 구현은 공백을 자동으로 지우지 않는다. + +--- + +### CHAT-SEND-003: 한글 조합 중 엔터를 눌러도 메시지가 전송되지 않는다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 입력기 조합 중 전송 방지 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | UI 조작 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +한글 입력 조합을 확정하는 엔터가 메시지 전송으로 잘못 처리되지 않는지 검증한다. + +## 시나리오 +사용자가 한글을 조합하는 도중 엔터를 누른다. + +## Given +- 로그인 세션을 주입하고 채팅방에 진입한다. +- 입력란에 조합 중인 문자가 있는 상태를 만든다. + +## When +- `isComposing`이 참인 키보드 이벤트로 엔터를 누른다. + +## Then +- 메시지가 화면에 추가되지 않는다. +- `chat_messages`에 새 행이 생성되지 않는다. +- 입력값이 전송 처리로 비워지지 않는다. + +## 테스트 데이터 +- 로그인 사용자 1명, 그룹 1개, 한글 조합 입력값 + +## 데이터 준비 방식 상세 +- 브라우저에서 입력 조합 이벤트를 발생시키고 데이터베이스 쓰기 여부를 API Helper로 확인한다. + +## Cleanup 대상 +- 생성되는 데이터가 없어 불필요하다. + +## 예외/주의사항 +- Playwright에서 실제 조합 이벤트 재현이 불안정하면 브라우저 이벤트를 명시적으로 발생시키는 보조 코드를 사용한다. + +--- + +### CHAT-SEND-004: 메시지 저장이 실패하면 해당 메시지가 실패 상태로 남는다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 메시지 전송 실패 처리 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +메시지 저장 실패를 사용자에게 표시하고 낙관적 메시지를 잃지 않는지 검증한다. + +## 시나리오 +사용자가 메시지를 전송하지만 Supabase 삽입 요청이 실패한다. + +## Given +- 로그인 세션을 주입하고 채팅방에 진입한다. +- `chat_messages` 삽입 요청이 오류를 반환하도록 Mock한다. + +## When +- 내용을 입력하고 엔터를 누른다. + +## Then +- 입력한 메시지가 화면에 남는다. +- 해당 메시지의 투명도가 낮아지고 실패 상태 문구가 함께 표시된다. +- 전송 실패 토스트가 표시된다. +- 데이터베이스에는 메시지가 생성되지 않는다. + +## 테스트 데이터 +- 로그인 사용자 1명, 그룹 1개, 실패시킬 메시지 내용 + +## 데이터 준비 방식 상세 +- 초기 조회는 통과시키고 삽입 요청만 오류로 응답하도록 네트워크를 Mock한다. + +## Cleanup 대상 +- 저장된 데이터가 없어 불필요하다. + +## 예외/주의사항 +- 실패 상태와 토스트의 정확한 한국어 문구는 깨진 소스 문자열을 복구한 뒤 보강한다. + +--- + +### CHAT-REALTIME-001: 다른 사용자가 보낸 새 메시지가 실시간으로 한 번만 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 실시간 메시지 수신 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +현재 채팅방의 삽입 이벤트를 구독하여 새 메시지를 중복 없이 표시하는지 검증한다. + +## 시나리오 +사용자 A가 채팅방을 보고 있는 동안 사용자 B가 메시지를 보낸다. + +## Given +- 사용자 A의 로그인 세션을 주입하고 채팅방에 진입한다. +- 사용자 B와 같은 그룹을 준비한다. + +## When +- API Helper로 사용자 B의 새 메시지를 같은 `nbread_id`에 삽입한다. + +## Then +- 새 메시지가 새로 고침 없이 표시된다. +- 메시지는 생성 시각에 맞는 위치에 표시된다. +- 같은 식별자의 실시간 이벤트가 다시 전달되어도 메시지는 1개만 표시된다. +- 화면이 새 메시지가 있는 아래쪽으로 이동한다. + +## 테스트 데이터 +- 그룹 1개, 사용자 A와 B, 사용자 B의 새 메시지 1개 + +## 데이터 준비 방식 상세 +- 사용자 A 세션을 주입하고 API Helper로 사용자 B 명의의 메시지를 삽입한다. + +## Cleanup 대상 +- 삽입한 채팅 메시지와 테스트 그룹 및 사용자 + +## 예외/주의사항 +- 실시간 구독 연결이 완료된 뒤 메시지를 삽입하도록 대기 조건을 둔다. + +--- + +### CHAT-HISTORY-003: 채팅 내역 조회가 실패하면 오류를 알리고 이전 화면으로 돌아간다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 채팅 내역 조회 실패 처리 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +초기 채팅 내역을 불러오지 못했을 때 오류 안내 후 안전하게 이전 화면으로 복귀하는지 검증한다. + +## 시나리오 +사용자가 채팅방에 들어가지만 메시지 조회 요청이 실패한다. + +## Given +- 로그인 세션을 주입한다. +- 브라우저 방문 기록에 채팅방 이전 화면을 준비한다. +- `chat_messages` 조회가 오류를 반환하도록 Mock한다. + +## When +- 채팅방에 진입한다. + +## Then +- 내역 조회 실패 토스트가 표시된다. +- 브라우저가 이전 화면으로 돌아간다. +- 채팅 입력 화면이 정상 화면으로 표시되지 않는다. + +## 테스트 데이터 +- 로그인 사용자 1명과 조회 실패 응답 + +## 데이터 준비 방식 상세 +- 채팅 메시지 조회 네트워크 요청만 실패시키고 이전 화면에서 채팅방으로 이동한다. + +## Cleanup 대상 +- 영구 데이터 변경이 없어 불필요하다. + +## 예외/주의사항 +- 토스트의 정확한 문구는 깨진 소스 문자열을 복구한 뒤 보강한다. + +--- + +### CHAT-NOTIFICATION-001: 채팅 발신자와 알림 비활성 사용자는 알림 대상에서 제외된다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 채팅 알림 대상 권한 필터링 | +| 케이스 유형 | 권한 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 권한 없음 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +채팅 발신자와 `chat_enabled`가 비활성인 참여자에게 채팅 알림이 발송되거나 기록되지 않는지 검증한다. + +## 시나리오 +발신자와 알림 수신 권한이 없는 참여자만 있는 그룹에서 새 채팅 웹훅이 실행된다. + +## Given +- 그룹과 제목을 준비한다. +- 발신자와 채팅 알림이 비활성인 참여자를 그룹에 추가한다. +- 두 사용자에게 FCM 토큰을 준비한다. + +## When +- 발신자의 채팅 메시지를 담은 `POST` 웹훅을 `chat-notification`에 보낸다. + +## Then +- 응답 상태는 204이다. +- 발신자와 알림 비활성 참여자에게 FCM 알림이 전송되지 않는다. +- 두 사용자에 대한 채팅 알림 이력이 생성되지 않는다. + +## 테스트 데이터 +- 그룹 1개, 발신자 1명, 채팅 알림 비활성 참여자 1명, 각 사용자의 FCM 토큰 + +## 데이터 준비 방식 상세 +- Seed로 그룹, 참여자, 알림 설정, FCM 토큰을 준비하고 함수 호출 결과와 알림 이력을 조회한다. + +## Cleanup 대상 +- 그룹, 참여자, 알림 설정, FCM 토큰, 생성 가능성이 있는 알림 이력 + +## 예외/주의사항 +- 외부 FCM 호출이 없었다는 검증을 위해 함수 테스트 환경의 전송 도구를 관찰하거나 Mock해야 한다. + +--- + +### CHAT-NOTIFICATION-002: 알림 대상 사용자의 모든 기기에 채팅 알림을 보내고 사용자별 이력은 하나만 저장한다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 채팅 알림 발송 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +알림 수신이 활성화된 참여자의 여러 기기로 알림을 보내되 알림 이력은 사용자별 한 건만 생성하는지 검증한다. + +## 시나리오 +발신자가 메시지를 보내고 수신자가 두 기기에서 알림을 받는다. + +## Given +- 제목이 있는 그룹과 발신자, 채팅 알림 활성 수신자를 준비한다. +- 수신자에게 FCM 토큰 2개를 준비한다. +- 두 FCM 전송이 모두 성공하도록 Mock한다. + +## When +- 발신자의 채팅 메시지를 담은 `POST` 웹훅을 호출한다. + +## Then +- 두 FCM 토큰 각각에 알림 전송이 요청된다. +- 응답 상태는 200이다. +- 응답 본문에 알림 전송 성공 메시지가 포함된다. +- 수신자의 알림 이력은 1개만 생성된다. +- 이력의 `is_read`는 거짓, `type`은 `chat`, `data.nbreadId`는 대상 그룹 식별자이다. + +## 테스트 데이터 +- 그룹 1개, 발신자와 수신자, 수신자의 FCM 토큰 2개 + +## 데이터 준비 방식 상세 +- 데이터는 Seed로 준비하고 FCM 토큰 발급 및 전송 응답은 Mock한다. + +## Cleanup 대상 +- 그룹, 참여자, FCM 토큰, 생성된 알림 이력 + +## 예외/주의사항 +- 알림 제목과 본문의 정확한 한국어 문구는 깨진 소스 문자열을 복구한 뒤 검증값을 확정한다. + +--- + +### CHAT-NOTIFICATION-003: 채팅 알림 요청의 메서드가 POST가 아니면 거부된다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 채팅 알림 요청 메서드 검증 | +| 케이스 유형 | 실패 | +| 우선순위 | P2 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +채팅 알림 함수가 허용하지 않는 요청 메서드를 처리하지 않는지 검증한다. + +## 시나리오 +클라이언트가 유효한 웹훅 형태의 본문을 POST가 아닌 메서드로 보낸다. + +## Given +- 함수가 JSON으로 해석할 수 있는 웹훅 본문을 준비한다. + +## When +- `PUT` 메서드로 `chat-notification` 함수를 호출한다. + +## Then +- 응답 상태는 405이다. +- 응답 본문은 `Method Not Allowed`이다. +- FCM 알림과 알림 이력이 생성되지 않는다. + +## 테스트 데이터 +- 유효한 형태의 채팅 웹훅 JSON 본문 + +## 데이터 준비 방식 상세 +- API Helper로 함수를 직접 호출한다. + +## Cleanup 대상 +- 데이터 변경이 없어 불필요하다. + +## 예외/주의사항 +- 함수가 메서드 검사 전에 `req.json()`을 실행하므로 반드시 유효한 JSON 본문을 포함한다. + +--- + +### CHAT-NOTIFICATION-004: 그룹 제목을 조회하지 못하면 채팅 알림 요청이 서버 오류로 끝난다 +| 속성 | 값 | +|---|---| +| 도메인 | 채팅 | +| 시나리오 | 채팅 알림 그룹 조회 실패 처리 | +| 케이스 유형 | 예외 | +| 우선순위 | P2 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +웹훅의 그룹을 찾을 수 없을 때 알림 처리를 중단하고 명시적인 오류를 반환하는지 검증한다. + +## 시나리오 +존재하지 않는 그룹 식별자로 채팅 알림 웹훅이 호출된다. + +## Given +- 데이터베이스에 존재하지 않는 `nbread_id`를 준비한다. + +## When +- 해당 식별자를 포함한 채팅 메시지 웹훅을 `POST`로 호출한다. + +## Then +- 응답 상태는 500이다. +- 응답 본문의 오류는 `Failed to get nbread title`이다. +- 참여자 조회와 FCM 알림 전송은 진행되지 않는다. +- 알림 이력이 생성되지 않는다. + +## 테스트 데이터 +- 존재하지 않는 그룹 식별자를 가진 웹훅 JSON 본문 + +## 데이터 준비 방식 상세 +- API Helper로 함수를 직접 호출하고 알림 이력이 없는지 조회한다. + +## Cleanup 대상 +- 데이터 변경이 없어 불필요하다. + +## 예외/주의사항 +- 외부 전송 미호출 검증이 필요하면 FCM 전송 도구를 Mock한다. diff --git a/llm-wiki/output/2026-08-14-e2e-tc-draft-community.md b/llm-wiki/output/2026-08-14-e2e-tc-draft-community.md new file mode 100644 index 0000000..9f66bd3 --- /dev/null +++ b/llm-wiki/output/2026-08-14-e2e-tc-draft-community.md @@ -0,0 +1,569 @@ +# 커뮤니티 도메인 E2E 테스트 케이스 초안 + +## 조사한 코드 +- `src/components/community/Community.tsx` +- `src/components/community/CreatePostButton.tsx` +- `src/components/community/UpdatePostBottomSheet.tsx` +- `src/components/community/PostCard.tsx` +- `src/components/community/DropdownMenu.tsx` +- `src/components/community/DeletePostModal.tsx` +- `src/components/community/NbreadTabs.tsx` +- `src/lib/post/getPost.ts` +- `src/lib/post/insertPost.ts` +- `src/lib/post/updatePost.ts` +- `src/lib/post/deletePost.ts` +- `src/types/post.ts` + +## 확인 필요 사항 +- 게시글 수정 및 삭제 메뉴가 작성자 여부와 관계없이 모든 게시글에 표시된다. 이 범위의 코드에는 작성자 또는 그룹장 권한 검사가 없으므로 의도한 권한 정책과 데이터베이스 접근 정책을 확인해야 한다. +- 게시글 작성, 수정, 삭제 함수가 오류를 호출자에게 전달하지 않으며 화면은 결과와 관계없이 성공 알림을 표시하고 목록을 다시 조회한다. 실패 시 의도한 사용자 경험을 확인해야 한다. +- 게시글 수정 화면에서 사용자가 기존 내용을 모두 지워도 실제 `disabled` 속성은 기존 게시글 내용만 검사하므로 버튼이 활성 상태다. 빈 내용 수정을 허용하는지 확인해야 한다. +- 게시글 본문 길이 제한과 별도 유효성 검사는 조사 범위에서 확인되지 않았다. 허용 길이와 데이터베이스 제약을 확인해야 한다. +- 게시글 작성 시 브라우저 현재 시각에 9시간을 더한 문자열을 저장한다. 실행 환경의 시간대와 무관하게 이 처리가 필요한지 확인해야 한다. +- `NbreadTabs.tsx`의 구현은 전부 주석 처리되어 있어 현재 테스트 대상 흐름에 포함하지 않았다. +- 소스의 사용자 표시 문구가 깨진 문자열로 보이므로, 접근 가능한 이름을 이용한 선택자를 확정하기 전에 실제 화면 문구와 파일 인코딩을 확인해야 한다. + +## 케이스 목록 + +### COMMUNITY-LIST-001: 커뮤니티에 들어가면 게시글을 불러오는 동안 로딩 표시가 보인다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 게시글 목록 조회 | +| 케이스 유형 | Smoke | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +게시글 조회가 끝나기 전까지 커뮤니티가 로딩 상태를 표시하는지 검증한다. + +## 시나리오 +사용자가 커뮤니티에 진입하고 지연된 게시글 조회 응답을 기다린다. + +## Given +- 로그인 세션이 주입되어 있다. +- 현재 경로에 유효한 `nbreadId`가 있다. +- `post` 조회 응답을 의도적으로 지연한다. + +## When +커뮤니티 화면에 진입한다. + +## Then +- 조회 완료 전 `Spinner`가 로딩 상태로 표시된다. +- 로딩 중 게시글 카드와 빈 상태 문구는 표시되지 않는다. + +## 테스트 데이터 +- 조회가 지연되는 게시글 응답 + +## 데이터 준비 방식 상세 +Playwright 네트워크 제어 또는 Supabase 클라이언트 Mock으로 조회 응답을 지연한다. + +## Cleanup 대상 +없음 + +## 예외/주의사항 +조회 완료 뒤에도 코드에 설정된 1초 지연이 지난 후 목록이 표시된다. + +--- + +### COMMUNITY-LIST-002: 게시글이 없으면 빈 상태 안내가 보인다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 빈 게시글 목록 조회 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +현재 엔빵에 게시글이 없을 때 빈 상태가 정상적으로 표시되는지 검증한다. + +## 시나리오 +게시글이 없는 엔빵의 커뮤니티를 연다. + +## Given +- 로그인 세션이 주입되어 있다. +- 대상 `nbreadId`에 속한 게시글이 없다. + +## When +커뮤니티 화면에 진입하고 로딩이 끝날 때까지 기다린다. + +## Then +- 게시글이 없다는 안내가 표시된다. +- 게시글 카드는 표시되지 않는다. +- 게시글 작성 버튼은 표시된다. + +## 테스트 데이터 +- 게시글이 없는 엔빵 1개 + +## 데이터 준비 방식 상세 +게시글이 연결되지 않은 엔빵을 Seed로 준비한다. + +## Cleanup 대상 +없음 + +## 예외/주의사항 +`getPost`가 오류로 `undefined`를 반환한 경우도 현재 구현에서는 빈 배열로 변환되므로 같은 화면이 표시된다. + +--- + +### COMMUNITY-LIST-003: 게시글 목록은 최신 작성일 순서로 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 게시글 목록 조회 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +조회 함수의 `created_at` 내림차순 정렬과 화면의 게시글 변환 결과를 검증한다. + +## 시나리오 +작성 시각이 서로 다른 게시글이 있는 커뮤니티를 연다. + +## Given +- 로그인 세션이 주입되어 있다. +- 같은 `nbreadId`에 작성 시각이 서로 다른 게시글 3개가 있다. + +## When +커뮤니티 화면에 진입하고 목록이 표시될 때까지 기다린다. + +## Then +- 가장 최근 게시글이 맨 위에 표시된다. +- 모든 게시글의 작성자 이름, 프로필 이미지, 본문이 각 Seed 값과 일치한다. +- 작성일은 `YYYY.MM.DD` 형식으로 표시된다. + +## 테스트 데이터 +- 동일 엔빵에 연결된 게시글 3개 +- 서로 다른 `created_at`, 본문, 작성자 이름 + +## 데이터 준비 방식 상세 +고정된 작성 시각을 가진 게시글을 Seed로 삽입한다. + +## Cleanup 대상 +삽입한 게시글 3개 + +## 예외/주의사항 +날짜 변환은 `new Date(raw.created_at).toISOString()`을 사용하므로 날짜 경계 테스트는 실행 환경과 원본 시각을 고정해야 한다. + +--- + +### COMMUNITY-CREATE-001: 내용을 입력하면 새 게시글을 작성하고 목록에 반영한다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 게시글 작성 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +작성 화면에서 입력한 내용과 로그인 사용자 및 현재 엔빵 정보로 게시글이 저장되고 목록이 갱신되는지 검증한다. + +## 시나리오 +로그인 사용자가 작성 버튼을 눌러 게시글을 등록한다. + +## Given +- 이름과 프로필 이미지가 있는 로그인 사용자 세션이 주입되어 있다. +- 현재 경로에 유효한 `nbreadId`가 있다. + +## When +- 게시글 작성 버튼을 누른다. +- 본문을 입력하고 작성 동작을 실행한다. + +## Then +- 작성 바텀시트가 닫힌다. +- 성공 알림이 표시된다. +- 목록 재조회 뒤 새 게시글의 본문과 사용자 이름이 표시된다. +- 저장된 행의 `user_id`, `user_name`, `profile_image`, `nbread_id`가 로그인 사용자와 현재 경로 값에 대응한다. + +## 테스트 데이터 +- 게시글 본문: `커뮤니티 작성 테스트 게시글` +- 로그인 사용자 아이디, 이름, 프로필 이미지 +- 대상 엔빵 아이디 + +## 데이터 준비 방식 상세 +Supabase Admin API로 테스트 계정과 세션을 준비하고 브라우저에 세션을 주입한다. + +## Cleanup 대상 +테스트에서 생성한 게시글 + +## 예외/주의사항 +저장 시각은 클라이언트에서 현재 시각에 9시간을 더해 생성하므로 정확한 시각보다는 형식과 목록 반영을 검증한다. + +--- + +### COMMUNITY-CREATE-002: 공백만 입력하면 게시글 작성 버튼을 사용할 수 없다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 게시글 작성 유효성 검사 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +빈 문자열이나 공백만 있는 게시글이 작성 동작으로 이어지지 않는지 검증한다. + +## 시나리오 +로그인 사용자가 작성 화면에 공백만 입력한다. + +## Given +- 로그인 세션이 주입되어 있다. +- 게시글 작성 바텀시트가 열려 있다. + +## When +본문 입력란에 공백과 줄바꿈만 입력한다. + +## Then +- 작성 버튼이 비활성화된다. +- 게시글 삽입 요청이 발생하지 않는다. +- 작성 바텀시트가 열린 상태를 유지한다. + +## 테스트 데이터 +- 공백과 줄바꿈으로만 구성된 문자열 + +## 데이터 준비 방식 상세 +세션을 주입한 뒤 화면에서 작성 바텀시트를 열고 입력한다. + +## Cleanup 대상 +없음 + +## 예외/주의사항 +버튼 상태는 `content.trim() === ''` 조건에 근거한다. + +--- + +### COMMUNITY-CREATE-003: 로그인 정보가 없으면 게시글을 저장하지 않는다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 비로그인 게시글 작성 차단 | +| 케이스 유형 | 권한 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +사용자 저장소에 로그인 사용자가 없을 때 작성 처리 함수가 저장을 중단하는지 검증한다. + +## 시나리오 +비로그인 상태에서 작성 화면에 유효한 내용을 입력하고 작성 동작을 시도한다. + +## Given +- 사용자 저장소의 `user`가 비어 있다. +- 작성 바텀시트가 열려 있다. + +## When +공백이 아닌 본문을 입력하고 작성 버튼을 누른다. + +## Then +- 게시글 삽입 요청이 발생하지 않는다. +- 성공 알림이 표시되지 않는다. +- 바텀시트가 열린 상태를 유지한다. + +## 테스트 데이터 +- 게시글 본문: `비로그인 작성 차단 테스트` + +## 데이터 준비 방식 상세 +인증 저장소를 비로그인 상태로 Mock하고 커뮤니티 컴포넌트에 접근한다. + +## Cleanup 대상 +없음 + +## 예외/주의사항 +라우트 자체의 비로그인 접근 가능 여부는 조사 범위에 없으므로 컴포넌트 수준에서 검증한다. + +--- + +### COMMUNITY-MENU-001: 게시글 메뉴 바깥을 누르면 메뉴가 닫힌다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 게시글 메뉴 닫기 | +| 케이스 유형 | 회귀 | +| 우선순위 | P2 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +게시글의 점 메뉴를 연 뒤 배경을 누르면 메뉴가 닫히는 상호작용을 검증한다. + +## 시나리오 +사용자가 게시글 메뉴를 열고 메뉴 바깥 영역을 누른다. + +## Given +- 로그인 세션이 주입되어 있다. +- 화면에 게시글 카드가 1개 표시되어 있다. + +## When +- 게시글의 점 메뉴를 누른다. +- 열린 메뉴의 바깥 배경을 누른다. + +## Then +- 수정 및 삭제 동작을 제공하는 메뉴가 먼저 표시된다. +- 배경을 누른 뒤 메뉴가 DOM에서 제거된다. +- 수정 바텀시트와 삭제 확인 모달은 열리지 않는다. + +## 테스트 데이터 +- 게시글 1개 + +## 데이터 준비 방식 상세 +대상 엔빵에 게시글을 Seed로 삽입한다. + +## Cleanup 대상 +삽입한 게시글 + +## 예외/주의사항 +점 메뉴 위치는 버튼의 화면 좌표를 기준으로 계산하므로 위치의 픽셀값 자체는 단언하지 않는다. + +--- + +### COMMUNITY-UPDATE-001: 기존 게시글을 수정하면 변경된 내용이 목록에 반영된다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 게시글 수정 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +수정 화면이 기존 내용을 불러오고 변경 내용을 저장한 뒤 목록을 갱신하는지 검증한다. + +## 시나리오 +로그인 사용자가 게시글 메뉴에서 수정을 선택하고 본문을 변경한다. + +## Given +- 로그인 세션이 주입되어 있다. +- 로그인 사용자가 작성한 게시글 1개가 표시되어 있다. + +## When +- 게시글 메뉴에서 수정 동작을 선택한다. +- 입력란의 기존 내용을 확인하고 새 내용으로 바꾼다. +- 수정 동작을 실행한다. + +## Then +- 수정 입력란에는 처음 열릴 때 기존 본문이 채워져 있다. +- 수정 바텀시트가 닫히고 성공 알림이 표시된다. +- 목록 재조회 뒤 변경된 본문이 표시되고 기존 본문은 표시되지 않는다. + +## 테스트 데이터 +- 기존 본문: `수정 전 게시글` +- 변경 본문: `수정 후 게시글` + +## 데이터 준비 방식 상세 +테스트 계정 소유의 게시글을 Seed로 삽입하고 해당 계정 세션을 주입한다. + +## Cleanup 대상 +수정한 게시글 + +## 예외/주의사항 +현재 수정 함수는 게시글 아이디와 본문만 사용한다. 데이터베이스의 소유권 정책은 별도로 확인해야 한다. + +--- + +### COMMUNITY-UPDATE-002: 수정 화면에서 본문을 모두 지워도 수정 요청을 보낸다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 빈 게시글 내용 수정 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +수정 버튼의 표시 상태와 실제 비활성 조건이 서로 다른 현재 동작을 회귀 기준으로 기록한다. + +## 시나리오 +기존 본문이 있는 게시글의 내용을 모두 지우고 수정 버튼을 누른다. + +## Given +- 로그인 세션이 주입되어 있다. +- 비어 있지 않은 본문을 가진 게시글의 수정 바텀시트가 열려 있다. +- 게시글 수정 요청을 관찰할 수 있도록 Mock한다. + +## When +- 입력란의 내용을 모두 지운다. +- 수정 버튼을 누른다. + +## Then +- 버튼은 비활성 모양의 클래스를 사용한다. +- 실제 `disabled` 속성은 적용되지 않아 버튼을 누를 수 있다. +- 빈 `content`와 게시글 아이디를 포함한 수정 요청이 발생한다. + +## 테스트 데이터 +- 기존 본문: `내용이 있는 게시글` +- 변경 본문: 빈 문자열 + +## 데이터 준비 방식 상세 +게시글 데이터와 Supabase 수정 응답을 Mock해 데이터베이스 제약과 무관하게 호출 여부를 검증한다. + +## Cleanup 대상 +없음 + +## 예외/주의사항 +의도한 동작인지 확인이 필요하다. 정책이 확정되면 기대 결과와 케이스 유형을 갱신한다. + +--- + +### COMMUNITY-DELETE-001: 삭제 확인에서 취소하면 게시글이 그대로 남는다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 게시글 삭제 취소 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +삭제 확인 모달에서 취소했을 때 삭제 요청 없이 원래 게시글을 유지하는지 검증한다. + +## 시나리오 +사용자가 게시글 삭제를 선택한 뒤 확인 모달에서 취소한다. + +## Given +- 로그인 세션이 주입되어 있다. +- 로그인 사용자가 작성한 게시글 1개가 표시되어 있다. + +## When +- 게시글 메뉴에서 삭제 동작을 선택한다. +- 삭제 확인 모달에서 취소 동작을 실행한다. + +## Then +- 삭제 확인 모달이 닫힌다. +- 게시글 삭제 요청이 발생하지 않는다. +- 대상 게시글이 목록에 그대로 표시된다. + +## 테스트 데이터 +- 삭제 취소 대상 게시글 1개 + +## 데이터 준비 방식 상세 +테스트 계정 소유의 게시글을 Seed로 삽입한다. + +## Cleanup 대상 +삽입한 게시글 + +## 예외/주의사항 +모달 문구의 정확한 문자열은 소스 인코딩 확인 후 선택자에 반영한다. + +--- + +### COMMUNITY-DELETE-002: 삭제를 확인하면 게시글이 목록에서 사라진다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 게시글 삭제 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 확인 필요 | +| 관련 Issue | | + +## 목적 +삭제 확인 시 게시글 아이디로 삭제하고 목록을 다시 조회하는 흐름을 검증한다. + +## 시나리오 +로그인 사용자가 게시글 삭제를 선택하고 확인한다. + +## Given +- 로그인 세션이 주입되어 있다. +- 로그인 사용자가 작성한 게시글 1개가 표시되어 있다. + +## When +- 게시글 메뉴에서 삭제 동작을 선택한다. +- 삭제 확인 모달에서 삭제 동작을 실행한다. + +## Then +- 삭제 확인 모달이 닫힌다. +- 성공 알림이 표시된다. +- 목록 재조회 뒤 대상 게시글이 표시되지 않는다. +- 마지막 게시글이었다면 빈 상태 안내가 표시된다. + +## 테스트 데이터 +- 삭제 대상 게시글 1개 + +## 데이터 준비 방식 상세 +테스트 계정 소유의 게시글을 Seed로 삽입하고 계정 세션을 주입한다. + +## Cleanup 대상 +삭제가 실패한 경우 남아 있는 대상 게시글 + +## 예외/주의사항 +정상 완료 시 대상 행은 이미 삭제되므로 별도 Cleanup이 없지만, 실패 시 정리가 필요해 `확인 필요`로 분류한다. + +--- + +### COMMUNITY-LIST-004: 게시글 조회가 실패하면 로딩 뒤 빈 상태를 표시한다 +| 속성 | 값 | +|---|---| +| 도메인 | 커뮤니티 | +| 시나리오 | 게시글 조회 실패 처리 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +조회 함수가 오류로 값을 반환하지 않을 때 화면이 중단되지 않고 현재 구현의 빈 상태로 전환되는지 검증한다. + +## 시나리오 +사용자가 커뮤니티에 진입하지만 게시글 조회가 오류로 끝난다. + +## Given +- 로그인 세션이 주입되어 있다. +- `getPost`가 오류로 `undefined`를 반환하도록 Mock한다. + +## When +커뮤니티 화면에 진입하고 로딩 지연이 끝날 때까지 기다린다. + +## Then +- 로딩 표시가 사라진다. +- 게시글 카드는 표시되지 않는다. +- 빈 상태 안내와 게시글 작성 버튼이 표시된다. +- 화면이 예외로 중단되지 않는다. + +## 테스트 데이터 +- 오류를 반환하는 게시글 조회 응답 + +## 데이터 준비 방식 상세 +Supabase 조회 오류 또는 `getPost`의 `undefined` 반환을 Mock한다. + +## Cleanup 대상 +없음 + +## 예외/주의사항 +현재 구현은 조회 실패와 실제 빈 목록을 사용자에게 구분해 보여주지 않는다. 별도 오류 화면이 필요한지는 확인 필요 사항이다. + diff --git a/llm-wiki/output/2026-08-14-e2e-tc-draft-friend.md b/llm-wiki/output/2026-08-14-e2e-tc-draft-friend.md new file mode 100644 index 0000000..da526dc --- /dev/null +++ b/llm-wiki/output/2026-08-14-e2e-tc-draft-friend.md @@ -0,0 +1,643 @@ +# 친구 도메인 E2E 테스트 케이스 초안 + +## 조사한 코드 +- `src/app/friendList/page.tsx` +- `src/components/friend/PlusFriendListItem.tsx` +- `src/components/friend/PlusFriendBottomSheet.tsx` +- `src/components/friend/FriendCard.tsx` +- `src/components/friend/FriendBottomSheet.tsx` +- `src/components/friend/FriendAcceptModal.tsx` +- `src/lib/friend/updateFriend.ts` +- `src/lib/friend/sendFriendRequest.ts` +- `src/lib/friend/getSearchFriend.ts` +- `supabase/functions/friend-request-notification/index.ts` +- `supabase/functions/friend-request-notification/deno.json` +- `supabase/functions/friend-response-notification/index.ts` +- `supabase/functions/friend-response-notification/deno.json` + +## 확인 필요 사항 +- `FriendCard`에서 `FriendBottomSheet` 렌더링 코드가 주석 처리되어 있다. 친구 카드를 눌렀을 때 상세 화면을 열려는 기획인지 확인이 필요하다. +- `FriendAcceptModal`을 여는 상위 컴포넌트가 조사 범위에 없어 친구 요청 수락 및 거절 모달의 실제 사용자 진입 경로를 확인할 수 없다. +- 친구 요청 수락 처리에서 요청 상태를 먼저 `accepted`로 바꾼 뒤 `friend` 삽입에 실패하면 상태를 되돌리지 않는다. 이때 기대하는 복구 방식과 사용자 안내 정책을 확인해야 한다. +- 친구 요청 생성이나 재요청이 실패해도 화면은 `요청 완료`로 바뀐다. 실패 시 화면을 되돌리거나 오류를 안내해야 하는지 확인이 필요하다. +- 친구 요청 거절 함수는 데이터베이스 오류를 확인하거나 호출자에게 결과를 반환하지 않는다. 실패 시 모달을 닫는 현재 동작이 의도한 것인지 확인이 필요하다. +- 친구 목록과 검색 실패는 모두 빈 배열로 처리되어 실제 빈 상태와 조회 오류를 화면에서 구분하지 않는다. 오류 화면이나 다시 시도 동작이 필요한지 확인해야 한다. +- 친구 응답 알림 함수는 요청 메서드와 본문 유효성을 검사하기 전에 `req.json()`을 호출한다. 본문 없는 `OPTIONS` 요청을 정상 처리해야 하는지 확인이 필요하다. +- 알림 발송 결과를 성공 항목만 필터링한 뒤 필터 결과의 인덱스로 원래 토큰 목록을 참조한다. 일부 토큰만 성공했을 때 알림 저장 대상이 올바른지 확인이 필요하다. + +## 케이스 목록 + +### FRIEND-LIST-001: 양쪽 위치에 저장된 친구가 모두 친구 목록에 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 친구 목록 조회 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +로그인 사용자가 `friend` 테이블에서 어느 사용자 열에 저장되어 있든 모든 친구를 볼 수 있는지 검증한다. + +## 시나리오 +친구 관계가 있는 사용자가 친구 목록에 들어간다. + +## Given +- 로그인 사용자 A의 세션을 주입한다. +- A가 `user_id_1`인 친구 B 관계와 A가 `user_id_2`인 친구 C 관계를 준비한다. +- B와 C의 사용자 이름, 태그, 프로필 정보를 준비한다. + +## When +- `/friendList`로 이동한다. + +## Then +- `친구 목록` 제목이 보인다. +- B와 C의 이름 및 `#태그`가 각각 보인다. + +## 테스트 데이터 +- 사용자 A, B, C +- A-B 및 C-A 친구 관계 + +## 데이터 준비 방식 상세 +Supabase Admin API 또는 테스트 시드로 사용자와 양방향 열 배치의 친구 관계를 만든 뒤 A의 세션을 브라우저에 주입한다. + +## Cleanup 대상 +생성한 친구 관계와 테스트 사용자를 삭제한다. + +## 예외/주의사항 +코드는 `user_id_1`과 `user_id_2`를 모두 조회한 뒤 로그인 사용자 반대편의 아이디를 친구로 선택한다. + +--- + +### FRIEND-LIST-002: 친구 관계가 없으면 친구 카드 없이 목록 화면이 열린다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 친구 목록 빈 상태 조회 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +친구가 없는 사용자의 목록 조회가 오류 없이 빈 결과로 처리되는지 검증한다. + +## 시나리오 +친구 관계가 없는 사용자가 친구 목록에 들어간다. + +## Given +- 친구 관계가 없는 사용자 A의 세션을 주입한다. + +## When +- `/friendList`로 이동한다. + +## Then +- `친구 목록`과 `친구 추가하기`가 보인다. +- 친구 이름과 태그를 담은 친구 카드는 보이지 않는다. +- 페이지 오류가 발생하지 않는다. + +## 테스트 데이터 +- 친구 관계가 없는 사용자 A + +## 데이터 준비 방식 상세 +사용자 A를 만들고 A가 포함된 `friend` 행이 없도록 보장한 뒤 세션을 주입한다. + +## Cleanup 대상 +테스트 사용자를 삭제한다. + +## 예외/주의사항 +별도의 친구 목록 빈 상태 문구는 코드에 없다. + +--- + +### FRIEND-SEARCH-001: 친구 추가하기를 누르면 태그 검색 창이 열린다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 친구 검색 창 열기 | +| 케이스 유형 | Smoke | +| 우선순위 | P0 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +친구 추가 흐름의 시작점인 바텀 시트가 정상적으로 열리는지 검증한다. + +## 시나리오 +로그인 사용자가 친구 목록에서 친구 추가하기를 누른다. + +## Given +- 로그인 사용자 세션을 주입하고 `/friendList`에 접속한다. + +## When +- `친구 추가하기`를 누른다. + +## Then +- `태그로 검색하기` 입력란이 보인다. +- `검색결과`와 `회원 태그를 검색해 초대할 수 있어요` 문구가 보인다. + +## 테스트 데이터 +- 로그인 사용자 1명 + +## 데이터 준비 방식 상세 +기존 테스트 계정의 세션만 브라우저에 주입한다. + +## Cleanup 대상 +없음 + +## 예외/주의사항 +바텀 시트 닫기 방식은 공통 `BottomSheet` 구현에 있으므로 이 케이스의 범위에서 제외한다. + +--- + +### FRIEND-SEARCH-002: 태그가 4자가 되기 전에는 친구 검색을 실행하지 않는다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 친구 태그 입력 제한 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +정확히 4자가 아닌 태그 입력에서 검색 요청과 검색 완료 상태가 발생하지 않는지 검증한다. + +## 시나리오 +사용자가 친구 검색 창에 3자 태그를 입력한다. + +## Given +- 로그인 세션을 주입하고 친구 검색 창을 연다. +- 친구 검색 데이터 요청을 관찰한다. + +## When +- 태그 입력란에 `abc`를 입력하고 1초 이상 기다린다. + +## Then +- 사용자 및 친구 요청 조회가 실행되지 않는다. +- `회원 태그를 검색해 초대할 수 있어요` 문구가 유지된다. +- `일치하는 회원태그가 없어요.` 문구는 보이지 않는다. + +## 테스트 데이터 +- 로그인 사용자 1명 + +## 데이터 준비 방식 상세 +세션을 주입하고 브라우저 요청 감시 또는 Supabase 요청 모킹으로 검색 호출 여부를 확인한다. + +## Cleanup 대상 +없음 + +## 예외/주의사항 +입력란의 `maxLength`가 4이므로 5자 이상 입력 검증은 별도 케이스로 만들지 않는다. + +--- + +### FRIEND-SEARCH-003: 정확한 4자 태그를 검색하면 일치하는 다른 사용자가 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 친구 태그 검색 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +정확히 4자인 태그 검색 결과에 대상 사용자의 정보와 친구 추가 동작이 표시되는지 검증한다. + +## 시나리오 +사용자 A가 사용자 B의 태그를 검색한다. + +## Given +- 사용자 A와 태그가 `b123`인 사용자 B를 준비하고 A의 세션을 주입한다. +- 두 사용자 사이에 친구 요청이나 친구 관계가 없다. + +## When +- 친구 검색 창에 `b123`을 입력하고 검색이 끝날 때까지 기다린다. + +## Then +- 검색 중 스피너가 표시된다. +- 약 1초의 입력 지연 뒤 B의 이름과 프로필이 표시된다. +- B의 행에 `친구 추가하기`가 표시된다. + +## 테스트 데이터 +- 사용자 A +- 태그 `b123`과 이름 및 프로필을 가진 사용자 B + +## 데이터 준비 방식 상세 +두 사용자를 시드하고 관계 데이터가 없는지 확인한 뒤 A의 세션을 주입한다. + +## Cleanup 대상 +테스트 사용자를 삭제한다. + +## 예외/주의사항 +검색은 태그 완전 일치 조건이며 입력 후 1초 지연을 사용한다. + +--- + +### FRIEND-SEARCH-004: 일치하는 4자 태그가 없으면 검색 결과 없음 문구가 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 친구 태그 검색 실패 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +존재하지 않는 태그 검색이 빈 결과 안내로 처리되는지 검증한다. + +## 시나리오 +사용자가 존재하지 않는 태그를 검색한다. + +## Given +- 로그인 사용자 A를 준비한다. +- 태그 `none`을 가진 다른 사용자가 없도록 보장한다. + +## When +- 친구 검색 창에 `none`을 입력하고 검색이 끝날 때까지 기다린다. + +## Then +- `일치하는 회원태그가 없어요.` 문구가 보인다. +- 친구 검색 결과 행은 보이지 않는다. + +## 테스트 데이터 +- 사용자 A +- 존재하지 않는 태그 `none` + +## 데이터 준비 방식 상세 +태그 충돌이 없는 테스트 사용자를 만들고 A의 세션을 주입한다. + +## Cleanup 대상 +테스트 사용자를 삭제한다. + +## 예외/주의사항 +조회 오류도 같은 빈 배열로 처리되므로 이 케이스에서는 정상 응답의 빈 결과임을 함께 확인한다. + +--- + +### FRIEND-SEARCH-005: 자신의 태그를 검색해도 자신은 결과에 표시되지 않는다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 자기 자신 친구 검색 차단 | +| 케이스 유형 | 권한 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +로그인 사용자가 자기 자신에게 친구 요청을 보낼 수 없도록 검색 결과에서 제외되는지 검증한다. + +## 시나리오 +로그인 사용자가 자신의 4자 태그를 검색한다. + +## Given +- 태그가 `self`인 사용자 A의 세션을 주입한다. + +## When +- 친구 검색 창에 `self`를 입력하고 검색이 끝날 때까지 기다린다. + +## Then +- A의 이름은 검색 결과에 표시되지 않는다. +- `일치하는 회원태그가 없어요.` 문구가 보인다. + +## 테스트 데이터 +- 태그 `self`인 사용자 A + +## 데이터 준비 방식 상세 +사용자 A를 만들고 동일 태그의 다른 사용자가 없도록 한 뒤 A의 세션을 주입한다. + +## Cleanup 대상 +테스트 사용자를 삭제한다. + +## 예외/주의사항 +검색 쿼리는 로그인 사용자 아이디를 `neq` 조건으로 제외한다. + +--- + +### FRIEND-REQUEST-001: 친구 관계가 없는 사용자에게 친구 요청을 보내면 요청 완료로 바뀐다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 새 친구 요청 보내기 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +관계 데이터가 없는 두 사용자 사이에 대기 중인 친구 요청이 생성되는지 검증한다. + +## 시나리오 +사용자 A가 검색 결과의 사용자 B에게 친구 요청을 보낸다. + +## Given +- 사용자 A와 4자 태그를 가진 사용자 B를 준비한다. +- 두 사용자 사이에 `friend_request` 행이 없다. +- A의 세션을 주입하고 B를 검색한다. + +## When +- B 행의 `친구 추가하기`를 누른다. + +## Then +- 화면의 동작 문구가 `요청 완료`로 바뀐다. +- A가 발신자이고 B가 수신자이며 상태가 `pending`인 요청 행이 하나 생성된다. +- 같은 문구를 다시 눌러도 추가 요청 행이 생성되지 않는다. + +## 테스트 데이터 +- 사용자 A와 B + +## 데이터 준비 방식 상세 +두 사용자를 시드하고 A의 세션을 주입한다. 동작 후 API Helper로 요청 행을 조회한다. + +## Cleanup 대상 +생성된 친구 요청과 테스트 사용자를 삭제한다. + +## 예외/주의사항 +버튼이 아니라 클릭 가능한 문단 요소로 구현되어 있으므로 텍스트를 기준으로 조작한다. + +--- + +### FRIEND-REQUEST-002: 대기 중인 친구 요청이 있으면 중복 요청을 보내지 않는다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 친구 요청 중복 방지 | +| 케이스 유형 | 회귀 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +두 사용자 사이에 어느 방향으로든 대기 중인 요청이 있으면 새 요청을 만들지 않는지 검증한다. + +## 시나리오 +사용자 A가 이미 요청을 보낸 사용자 B를 다시 검색한다. + +## Given +- 사용자 A와 B를 준비한다. +- A와 B 사이에 상태가 `pending`인 요청 행을 준비한다. +- A의 세션을 주입한다. + +## When +- B의 태그를 검색한다. + +## Then +- B 행에 `요청 완료`가 표시된다. +- `친구 추가하기`는 표시되지 않는다. +- 행을 눌러도 기존 요청 외에 새 요청 행이 생기지 않는다. + +## 테스트 데이터 +- 사용자 A와 B +- 대기 중인 친구 요청 1건 + +## 데이터 준비 방식 상세 +사용자와 요청 행을 시드한 뒤 A의 세션을 주입한다. + +## Cleanup 대상 +친구 요청과 테스트 사용자를 삭제한다. + +## 예외/주의사항 +검색 로직은 요청 방향과 무관하게 두 사용자의 기존 요청 상태를 찾는다. + +--- + +### FRIEND-REQUEST-003: 거절된 친구 요청은 다시 보낼 수 있다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 거절된 친구 요청 다시 보내기 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +거절된 기존 요청을 새 행으로 중복 생성하지 않고 대기 상태로 갱신하는지 검증한다. + +## 시나리오 +사용자 A가 이전에 거절된 사용자 B에게 다시 친구 요청을 보낸다. + +## Given +- 사용자 A와 B 사이에 A가 발신자인 `rejected` 요청 행을 준비한다. +- A의 세션을 주입하고 B를 검색한다. + +## When +- B 행의 `친구 추가하기`를 누른다. + +## Then +- 화면 문구가 `요청 완료`로 바뀐다. +- 기존 요청 행의 상태가 `pending`으로 바뀐다. +- 두 사용자 사이의 요청 행 개수는 증가하지 않는다. + +## 테스트 데이터 +- 사용자 A와 B +- A가 발신자인 거절된 친구 요청 1건 + +## 데이터 준비 방식 상세 +사용자와 거절된 요청을 시드한 뒤 A의 세션을 주입한다. 동작 전후 행 아이디와 상태를 API Helper로 비교한다. + +## Cleanup 대상 +친구 요청과 테스트 사용자를 삭제한다. + +## 예외/주의사항 +재요청 갱신은 현재 로그인 사용자가 기존 행의 발신자인 방향에만 `eq` 조건이 적용된다. 반대 방향의 거절 요청 동작은 확인 필요 사항이다. + +--- + +### FRIEND-REQUEST-004: 수락된 요청 관계는 검색 결과에서 추가 동작을 노출하지 않는다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 수락된 친구 요청 표시 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +이미 수락된 관계에 친구 추가나 요청 완료 동작이 잘못 표시되지 않는지 검증한다. + +## 시나리오 +사용자 A가 수락된 요청 관계의 사용자 B를 검색한다. + +## Given +- 사용자 A와 B 사이에 상태가 `accepted`인 요청 행을 준비한다. +- A의 세션을 주입한다. + +## When +- B의 태그를 검색한다. + +## Then +- B의 이름은 표시된다. +- B 행에 `친구 추가하기`와 `요청 완료`가 모두 표시되지 않는다. +- 새 친구 요청 행은 생성되지 않는다. + +## 테스트 데이터 +- 사용자 A와 B +- 수락된 친구 요청 1건 + +## 데이터 준비 방식 상세 +사용자와 수락된 요청을 시드하고 A의 세션을 주입한다. + +## Cleanup 대상 +친구 요청과 테스트 사용자를 삭제한다. + +## 예외/주의사항 +컴포넌트는 `pending`, `rejected`, 신규 상태 외에는 빈 동작 문구를 사용한다. + +--- + +### FRIEND-NOTIFICATION-001: 잘못된 친구 요청 알림 본문은 오류 응답을 반환한다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 친구 요청 알림 본문 검증 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 관리자 또는 그룹장 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +친구 요청 알림 함수가 JSON으로 해석할 수 없는 본문을 명시적인 클라이언트 오류로 처리하는지 검증한다. + +## 시나리오 +친구 요청 알림 함수에 잘못된 POST 본문을 보낸다. + +## Given +- 배포된 `friend-request-notification` 함수 호출 권한과 주소를 준비한다. + +## When +- JSON이 아닌 본문으로 POST 요청을 보낸다. + +## Then +- 응답 상태는 400이다. +- 응답 본문의 오류는 `Invalid payload`이다. + +## 테스트 데이터 +- JSON이 아닌 문자열 본문 + +## 데이터 준비 방식 상세 +Playwright의 API 요청 기능으로 함수 엔드포인트를 직접 호출한다. + +## Cleanup 대상 +없음 + +## 예외/주의사항 +외부 알림 제공자 호출 전 종료되는 분기다. + +--- + +### FRIEND-NOTIFICATION-002: 알림을 받지 않는 사용자의 친구 요청 알림은 발송 없이 끝난다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 친구 요청 알림 수신 설정 적용 | +| 케이스 유형 | 권한 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +수신자의 친구 알림 설정이 꺼져 있으면 기기 알림과 알림 저장을 수행하지 않는지 검증한다. + +## 시나리오 +알림 수신을 허용하지 않은 사용자에게 친구 요청 알림 웹훅이 실행된다. + +## Given +- 발신자 A와 수신자 B를 준비한다. +- B의 `friend_enabled` 알림 설정을 끈다. +- A의 이름 조회가 가능하도록 사용자 데이터를 준비한다. + +## When +- A가 발신자이고 B가 수신자인 레코드 본문으로 `friend-request-notification`에 POST 요청을 보낸다. + +## Then +- 응답 상태는 204이다. +- B를 대상으로 한 `friend_request` 유형 알림 저장 행이 생성되지 않는다. + +## 테스트 데이터 +- 사용자 A와 B +- B의 비활성 친구 알림 설정 + +## 데이터 준비 방식 상세 +사용자와 알림 설정을 시드하고 Playwright API 요청으로 함수 엔드포인트를 호출한다. + +## Cleanup 대상 +테스트 사용자와 알림 설정을 삭제한다. + +## 예외/주의사항 +코드는 활성 수신 대상이 없으면 FCM 토큰 조회 전에 204로 끝난다. + +--- + +### FRIEND-NOTIFICATION-003: 이미 수락된 요청의 응답 알림은 다시 발송되지 않는다 +| 속성 | 값 | +|---|---| +| 도메인 | 친구 | +| 시나리오 | 친구 응답 알림 중복 방지 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 관리자 또는 그룹장 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +기존 상태가 이미 수락인 요청 업데이트에서 응답 알림이 중복 생성되지 않는지 검증한다. + +## 시나리오 +이전 상태가 `accepted`인 친구 요청 업데이트 웹훅을 호출한다. + +## Given +- `old_record.status`가 `accepted`인 웹훅 본문을 준비한다. +- 호출 전 관련 알림 저장 행 개수를 기록한다. + +## When +- 본문을 `friend-response-notification`에 POST로 보낸다. + +## Then +- 응답 상태는 204이다. +- `friend_response` 유형 알림 저장 행 개수는 증가하지 않는다. + +## 테스트 데이터 +- 이전 상태와 현재 상태가 모두 `accepted`인 친구 요청 웹훅 본문 + +## 데이터 준비 방식 상세 +Playwright API 요청으로 함수 엔드포인트를 호출하고 서비스 역할 API로 알림 행 개수를 확인한다. + +## Cleanup 대상 +없음 + +## 예외/주의사항 +이 분기는 사용자나 FCM 토큰 조회 전에 종료된다. + diff --git a/llm-wiki/output/2026-08-14-e2e-tc-draft-group.md b/llm-wiki/output/2026-08-14-e2e-tc-draft-group.md new file mode 100644 index 0000000..9b81f4f --- /dev/null +++ b/llm-wiki/output/2026-08-14-e2e-tc-draft-group.md @@ -0,0 +1,735 @@ +# 그룹 도메인 E2E 테스트 케이스 초안 + +## 조사한 코드 +- `src/app/nbread/create/page.tsx` +- `src/app/nbread/preview/page.tsx` +- `src/app/nbread/[nbreadId]/page.tsx` +- `src/app/home/page.tsx` +- `src/app/calendar/page.tsx` +- `src/components/nbread/NbreadDetail.tsx` +- `src/components/nbread/nbreadCard.tsx` +- `src/components/nbread/nbreadEditCard.tsx` +- `src/components/nbread/nbreadParticipantCard.tsx` +- `src/components/nbread/nbreadParticipantsList.tsx` +- `src/components/home/Emptylog.tsx` +- `src/components/home/Header.tsx` +- `src/components/home/MonthlyNbread.tsx` +- `src/components/home/MyNbread.tsx` +- `src/components/home/MyNbreadList.tsx` +- `src/components/home/NbreadCard.tsx` +- `src/components/home/NbreadList.tsx` +- `src/components/home/ReceivedInviteBanner.tsx` +- `src/components/calendar/calendar.tsx` +- `src/lib/nbread/deleteNbread.ts` +- `src/lib/nbread/fetchNbreadData.ts` +- `src/lib/nbread/getNbread.ts` +- `src/lib/nbread/getUserNbread.ts` +- `src/lib/nbread/getUserTotalNbreadAmount.ts` +- `src/lib/nbread/index.ts` +- `src/lib/nbread/insertLink.ts` +- `src/lib/nbread/insertNbread.ts` +- `src/lib/nbread/updateNbread.ts` +- `src/stores/useNbreadStore.tsx` + +## 확인 필요 사항 +- 그룹 상세 조회나 참여자 조회가 실패했을 때 `src/app/nbread/[nbreadId]/page.tsx`에는 오류 안내와 이동 처리가 없어 로딩 화면에 머물거나 처리되지 않은 오류가 발생할 수 있다. 기대 동작을 확인해야 한다. +- 그룹 상세에서 정보 수정 요청이 실패했을 때 오류 안내가 없고 편집 상태가 즉시 전환된다. 실패 시 화면과 데이터의 기대 상태를 확인해야 한다. +- 그룹 탈퇴 실패 처리에서도 성공 토스트인 `엔빵 나가기에 실패했어요.`를 호출한다. 실패 토스트 사용 여부를 확인해야 한다. +- 캘린더의 결제 표시 점은 `nbread_records.payment_date`를 사용하지만, 선택한 날짜의 그룹 목록은 그룹의 `startDate`, `endDate`, `paymentDate`를 비교한다. 두 날짜 체계가 의도적으로 다른지 확인해야 한다. +- 생성 화면의 총 금액은 `type="number"`와 필수 여부만 검증한다. 0원, 음수, 소수 금액을 허용하는지 코드만으로 판단할 수 없다. +- 그룹 상세 주소의 `tab` 검색 매개변수는 값이 `chat`일 때만 채팅 탭을 초기 선택하며 게시판을 직접 여는 값은 없다. 의도된 주소 규칙인지 확인해야 한다. + +## 케이스 목록 + +### GROUP-CREATE-001: 필수 정보를 입력하면 그룹 미리보기로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 그룹 생성 정보 입력 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +그룹 생성 화면에서 유효한 정보를 입력한 뒤 저장하면 입력값과 그룹장 정보가 미리보기로 전달되는지 검증한다. + +## 시나리오 +로그인 사용자가 그룹의 금액, 제목, 참여 인원, 결제 주기와 결제일을 입력하고 저장한다. + +## Given +- 로그인 사용자 세션을 주입했다. +- `/nbread/create`에 진입했다. + +## When +- 총 금액, 타이틀, 참여 인원, 결제 주기와 결제일을 입력한다. +- 저장하기 버튼을 누른다. + +## Then +- `/nbread/preview`로 이동한다. +- 미리보기에 입력한 제목, 총 금액, 참여 인원, 나눈 금액과 정기 결제일이 표시된다. +- 로그인 사용자가 그룹장인 참여자로 표시된다. + +## 테스트 데이터 +- 총 금액: 12000원 +- 타이틀: 테스트 구독 +- 참여 인원: 3명 +- 결제 주기: 매월 +- 결제일: 15일 + +## 데이터 준비 방식 상세 +Supabase Admin API로 만든 로그인 세션을 브라우저에 주입하고 나머지 값은 화면에서 입력한다. + +## Cleanup 대상 +아직 데이터베이스에 그룹을 저장하지 않으므로 없다. + +## 예외/주의사항 +미리보기 단계까지만 검증하며 실제 그룹 생성 버튼은 누르지 않는다. + +--- + +### GROUP-CREATE-002: 필수 입력값이 없으면 저장하기 버튼을 누를 수 없다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 그룹 생성 입력값 검증 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +총 금액과 타이틀이 필수인 생성 폼에서 불완전한 값으로 다음 단계에 진입하지 못하는지 검증한다. + +## 시나리오 +로그인 사용자가 필수 입력값을 비워 둔 채 저장을 시도한다. + +## Given +- 로그인 사용자 세션을 주입했다. +- 저장된 생성 초안이 없는 상태로 `/nbread/create`에 진입했다. + +## When +- 총 금액 또는 타이틀 중 하나 이상을 비워 둔다. + +## Then +- 저장하기 버튼이 비활성화된다. +- `/nbread/preview`로 이동하지 않는다. + +## 테스트 데이터 +- 총 금액과 타이틀이 모두 빈 경우 +- 총 금액만 입력한 경우 +- 타이틀만 입력한 경우 + +## 데이터 준비 방식 상세 +로그인 세션만 주입하고 입력값은 화면에서 조작한다. + +## Cleanup 대상 +없다. + +## 예외/주의사항 +각 데이터 조합은 한 테스트 안에서 값을 지우고 다시 입력해 동일한 저장 버튼 상태를 확인한다. + +--- + +### GROUP-CREATE-003: 금액과 인원을 바꾸면 나눈 금액이 반올림되어 갱신된다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 그룹 생성 금액 계산 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +생성 폼의 나눈 금액이 총 금액과 참여 인원 변경을 반영하고 직접 편집할 수 없는지 검증한다. + +## 시나리오 +사용자가 나누어떨어지지 않는 총 금액과 참여 인원을 선택한다. + +## Given +- 로그인 사용자 세션을 주입했다. +- `/nbread/create`에 진입했다. + +## When +- 총 금액에 10000을 입력한다. +- 참여 인원을 3명으로 변경한다. + +## Then +- 엔빵 금액에 `3333`이 표시된다. +- 엔빵 금액 입력란은 비활성화되어 직접 수정할 수 없다. + +## 테스트 데이터 +- 총 금액: 10000원 +- 참여 인원: 3명 + +## 데이터 준비 방식 상세 +로그인 세션을 주입하고 생성 폼을 화면에서 조작한다. + +## Cleanup 대상 +없다. + +## 예외/주의사항 +생성 폼은 `Math.round`를 사용한다. 홈과 상세 카드의 금액 계산은 `Math.floor`를 사용하므로 계산 방식 차이는 별도 확인 대상이 될 수 있다. + +--- + +### GROUP-PREVIEW-001: 생성 초안 없이 미리보기에 접근하면 생성 화면으로 돌아간다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 그룹 미리보기 직접 접근 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +상태 저장소에 생성 초안이 없는 사용자가 미리보기 주소로 직접 접근했을 때 빈 미리보기를 노출하지 않는지 검증한다. + +## 시나리오 +로그인 사용자가 생성 화면을 거치지 않고 미리보기 주소를 연다. + +## Given +- 로그인 사용자 세션을 주입했다. +- Zustand 그룹 생성 상태가 `null`인 새 브라우저 문맥이다. + +## When +- `/nbread/preview`에 직접 진입한다. + +## Then +- 먼저 그룹을 작성해 달라는 오류 토스트가 표시된다. +- `/nbread/create`로 이동한다. + +## 테스트 데이터 +- 그룹 생성 초안 없음 + +## 데이터 준비 방식 상세 +새 브라우저 문맥에 로그인 세션만 주입하고 생성 화면 조작 없이 주소로 직접 이동한다. + +## Cleanup 대상 +없다. + +## 예외/주의사항 +이 흐름은 클라이언트 상태 유무에 의존하므로 테스트 사이에 브라우저 문맥을 공유하지 않는다. + +--- + +### GROUP-CREATE-004: 미리보기에서 그룹을 만들면 홈으로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 그룹 생성 완료 | +| 케이스 유형 | Smoke | +| 우선순위 | P0 | +| 데이터 준비 방식 | UI 조작 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +생성 폼부터 미리보기를 거쳐 그룹과 그룹장 참여 정보가 실제로 저장되는 핵심 흐름을 검증한다. + +## 시나리오 +로그인 사용자가 미리보기 내용을 확인하고 그룹 만들기를 완료한다. + +## Given +- 로그인 사용자 세션을 주입했다. +- 생성 화면에서 유효한 그룹 정보를 입력해 미리보기에 진입했다. + +## When +- 엔빵 만들기 버튼을 누른다. + +## Then +- 그룹 생성 성공 토스트가 표시된다. +- `/home`으로 이동한다. +- 나의 엔빵 목록에 생성한 제목의 그룹이 표시된다. +- 생성한 그룹의 참여자에 로그인 사용자가 그룹장으로 저장된다. + +## 테스트 데이터 +- 고유 제목: `E2E 그룹 생성 {실행 식별자}` +- 총 금액: 24000원 +- 참여 인원: 2명 +- 결제 주기: 매월 +- 결제일: 20일 + +## 데이터 준비 방식 상세 +세션만 주입한 뒤 생성 화면과 미리보기를 모두 화면 조작으로 진행한다. + +## Cleanup 대상 +- 생성된 `nbread` 행 +- 생성된 그룹장 `participant` 행과 연관 데이터 + +## 예외/주의사항 +그룹 생성 직후 생성 상태를 비우고 홈으로 이동하므로 뒤로 이동했을 때 같은 요청이 다시 실행되지 않는지도 함께 관찰한다. + +--- + +### GROUP-CREATE-005: 그룹 저장 요청이 실패하면 생성 화면으로 돌아간다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 그룹 생성 저장 실패 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +미리보기에서 그룹 저장이 실패했을 때 성공으로 오인하지 않고 재입력 가능한 화면으로 이동하는지 검증한다. + +## 시나리오 +사용자가 그룹 만들기 버튼을 눌렀지만 그룹 저장 요청이 실패한다. + +## Given +- 로그인 사용자 세션을 주입했다. +- 유효한 생성 초안으로 `/nbread/preview`에 진입했다. +- `nbread` 삽입 요청이 오류를 반환하도록 대체했다. + +## When +- 엔빵 만들기 버튼을 누른다. + +## Then +- 그룹 만들기에 실패했다는 오류 토스트가 표시된다. +- `/nbread/create`로 이동한다. +- 홈으로 이동하지 않는다. + +## 테스트 데이터 +- 유효한 그룹 생성 초안 +- Supabase 그룹 삽입 오류 응답 + +## 데이터 준비 방식 상세 +세션과 생성 초안을 준비하고 네트워크 계층에서 Supabase 그룹 삽입 응답만 실패로 대체한다. + +## Cleanup 대상 +삽입 요청이 실패하므로 없다. + +## 예외/주의사항 +그룹 삽입은 성공하고 참여자 삽입만 실패하는 경우 부분 저장이 발생할 수 있으나 보상 삭제가 코드에 없어 기대 정책 확인 전에는 독립 케이스로 만들지 않는다. + +--- + +### GROUP-HOME-001: 홈은 이번 달 그룹과 전체 참여 그룹을 구분해 보여준다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 홈 그룹 목록 조회 | +| 케이스 유형 | 회귀 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +홈이 매월 그룹과 이번 달에 결제하는 매년 그룹만 이번 달 목록에 포함하고, 모든 참여 그룹은 나의 엔빵에 표시하는지 검증한다. + +## 시나리오 +서로 다른 결제 주기의 여러 그룹에 참여한 사용자가 홈을 연다. + +## Given +- 로그인 사용자 세션을 주입했다. +- 사용자가 매월 그룹, 현재 월에 결제하는 매년 그룹, 다른 월에 결제하는 매년 그룹에 참여하고 있다. + +## When +- `/home`에 진입해 로딩이 끝날 때까지 기다린다. + +## Then +- 이번 달 엔빵에는 매월 그룹과 현재 월에 결제하는 매년 그룹만 표시된다. +- 다른 월에 결제하는 매년 그룹은 이번 달 엔빵에 표시되지 않는다. +- 나의 엔빵에는 세 그룹이 모두 표시되고 개수가 3개로 표시된다. +- 이번 달 합계는 이번 달 목록에 포함된 각 그룹의 `총 금액 / 참여 인원`을 내림한 값의 합이다. + +## 테스트 데이터 +- 매월 그룹: 10000원, 3명 +- 현재 월 매년 그룹: 12000원, 2명, 결제월은 테스트 실행 월 +- 다른 월 매년 그룹: 24000원, 4명, 결제월은 테스트 실행 월이 아닌 월 + +## 데이터 준비 방식 상세 +사용자, 그룹 세 개, 각 그룹의 참여자와 현재 회차 기록을 Seed로 만든 뒤 사용자 세션을 주입한다. + +## Cleanup 대상 +- 생성한 그룹, 참여자, 그룹 기록 데이터 + +## 예외/주의사항 +현재 월은 브라우저의 `new Date()`를 기준으로 계산하므로 테스트 실행 시점에 맞춰 Seed 결제월을 만든다. + +--- + +### GROUP-HOME-002: 참여 중인 그룹이 없으면 빈 상태와 추가 동선을 보여준다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 홈 그룹 빈 상태 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +참여 그룹이 없는 사용자에게 빈 상태를 안내하고 그룹 생성 진입점을 제공하는지 검증한다. + +## 시나리오 +참여 그룹이 없는 로그인 사용자가 홈에서 그룹 추가를 선택한다. + +## Given +- 그룹 참여 이력이 없는 사용자와 로그인 세션을 준비했다. + +## When +- `/home`에 진입해 로딩이 끝날 때까지 기다린다. +- 엔빵 추가하기를 누른다. + +## Then +- 이번 달 엔빵 영역에 `등록된 엔빵이 없어요`와 `엔빵을 추가해보세요!`가 표시된다. +- 나의 엔빵 개수 문구는 표시되지 않는다. +- `/nbread/create`로 이동한다. + +## 테스트 데이터 +- 참여 그룹이 없는 테스트 사용자 + +## 데이터 준비 방식 상세 +참여자 행이 없는 사용자 계정을 Seed로 만들고 세션을 주입한다. + +## Cleanup 대상 +- 테스트 사용자 + +## 예외/주의사항 +초대 배너는 별도 도메인이므로 이 사용자에게 대기 중 초대가 없도록 준비한다. + +--- + +### GROUP-DETAIL-001: 홈의 그룹 카드를 누르면 그룹 정보 탭으로 진입한다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 그룹 상세 진입 | +| 케이스 유형 | Smoke | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +홈 목록에서 선택한 그룹의 상세 주소로 이동하고 기본 그룹 정보 구조를 렌더링하는지 검증한다. + +## 시나리오 +참여 중인 사용자가 홈의 나의 엔빵 카드에서 그룹을 선택한다. + +## Given +- 로그인 사용자가 한 그룹에 참여하고 있다. +- 해당 그룹, 참여자, 현재 회차 기록이 준비되어 있다. +- `/home`의 나의 엔빵 목록에 그룹 카드가 표시된다. + +## When +- 그룹 카드를 누른다. + +## Then +- `/nbread/{그룹 아이디}`로 이동한다. +- 그룹 제목과 `엔빵 정보`, `게시판`, `채팅방` 탭이 표시된다. +- 기본 선택된 엔빵 정보 탭에 총 금액, 참여 인원, 엔빵 금액, 정기 결제일과 참여자 목록이 표시된다. + +## 테스트 데이터 +- 제목: E2E 상세 진입 그룹 +- 총 금액: 30000원 +- 참여 인원: 3명 +- 결제 주기: 매월 +- 결제일: 10일 + +## 데이터 준비 방식 상세 +그룹, 로그인 사용자의 참여자 정보와 현재 회차 기록을 Seed로 준비하고 세션을 주입한다. + +## Cleanup 대상 +- 생성한 그룹, 참여자, 그룹 기록 데이터 + +## 예외/주의사항 +게시판과 채팅방은 탭의 존재와 전환 구조만 그룹 도메인 범위이며 내부 기능은 검증하지 않는다. + +--- + +### GROUP-PERMISSION-001: 일반 참여자는 그룹을 수정할 수 없고 나가기만 선택할 수 있다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 그룹 상세 권한 구분 | +| 케이스 유형 | 권한 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 권한 없음 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +그룹장이 아닌 참여자에게 그룹 수정 권한을 노출하지 않고 탈퇴 동선만 제공하는지 검증한다. + +## 시나리오 +일반 참여자가 자신이 속한 그룹 상세를 연다. + +## Given +- 그룹장과 일반 참여자 계정을 준비했다. +- 일반 참여자 세션을 주입했다. +- 두 계정이 같은 그룹에 참여하고 있다. + +## When +- 일반 참여자가 `/nbread/{그룹 아이디}`에 진입한다. + +## Then +- 수정하기 버튼이 표시되지 않는다. +- 엔빵 삭제하기 버튼이 표시되지 않는다. +- 엔빵 나가기 버튼이 표시된다. + +## 테스트 데이터 +- 그룹장 1명과 일반 참여자 1명이 속한 그룹 + +## 데이터 준비 방식 상세 +그룹장 소유 그룹과 두 참여자 행, 현재 회차 기록을 Seed로 만들고 일반 참여자의 세션을 주입한다. + +## Cleanup 대상 +- 생성한 그룹, 참여자, 그룹 기록, 테스트 계정 데이터 + +## 예외/주의사항 +화면 노출 권한을 검증하는 케이스이며 데이터베이스의 행 수준 보안 정책 자체는 이 코드 범위에서 판단하지 않는다. + +--- + +### GROUP-DELETE-001: 그룹장은 편집 화면에서 그룹을 삭제하고 홈으로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 그룹 삭제 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 관리자/그룹장 | +| Cleanup | 확인 필요 | +| 관련 Issue | | + +## 목적 +그룹장이 상세 편집 상태에서 삭제를 확정하면 그룹이 삭제되고 홈으로 이동하는지 검증한다. + +## 시나리오 +그룹장이 자신의 그룹 상세에서 수정하기를 누른 뒤 그룹 삭제를 확정한다. + +## Given +- 그룹장 세션을 주입했다. +- 그룹장 소유 그룹과 필요한 참여자 및 현재 회차 기록이 준비되어 있다. +- 그룹 상세의 엔빵 정보 탭에 진입했다. + +## When +- 수정하기를 누른다. +- 엔빵 삭제하기를 누른다. +- 삭제 확인 창에서 삭제를 확정한다. + +## Then +- 그룹 삭제 성공 토스트가 표시된다. +- `/home`으로 이동한다. +- 삭제한 그룹이 홈의 나의 엔빵 목록에 표시되지 않는다. + +## 테스트 데이터 +- 그룹장 소유의 고유 제목 그룹 + +## 데이터 준비 방식 상세 +그룹, 그룹장 참여자와 현재 회차 기록을 Seed로 준비하고 그룹장 세션을 주입한다. + +## Cleanup 대상 +- 삭제가 연관 데이터를 함께 제거하는지 확인하고 남은 참여자 및 그룹 기록이 있으면 API Helper로 정리한다. + +## 예외/주의사항 +연관 데이터 삭제 방식은 조사한 그룹 코드에 나타나지 않아 Cleanup을 확인 필요로 둔다. + +--- + +### GROUP-DELETE-002: 그룹 삭제 요청이 실패하면 상세 화면에 머문다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 그룹 삭제 실패 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 관리자/그룹장 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +그룹 삭제 요청 실패 시 홈으로 이동하거나 성공으로 안내하지 않는지 검증한다. + +## 시나리오 +그룹장이 삭제를 확정하지만 Supabase 삭제 요청이 실패한다. + +## Given +- 그룹장 세션과 그룹 상세 데이터를 준비했다. +- 그룹 삭제 요청이 오류를 반환하도록 대체했다. +- 그룹 상세에서 편집 상태로 전환했다. + +## When +- 엔빵 삭제하기를 누르고 삭제를 확정한다. + +## Then +- 그룹 삭제에 실패했다는 오류 토스트가 표시된다. +- 현재 그룹 상세 주소에 머문다. +- 그룹 데이터가 유지된다. + +## 테스트 데이터 +- 그룹장 소유 그룹 +- Supabase 그룹 삭제 오류 응답 + +## 데이터 준비 방식 상세 +그룹 데이터는 Seed로 만들고 삭제 요청 응답만 네트워크 계층에서 실패로 대체한다. + +## Cleanup 대상 +- 실패 후 남아 있는 그룹, 참여자, 그룹 기록 데이터 + +## 예외/주의사항 +실패 시 삭제 확인 창을 닫는 코드가 없으므로 창 유지 여부는 현재 렌더링 결과를 관찰하되 기획 기대값으로 단정하지 않는다. + +--- + +### GROUP-QUIT-001: 일반 참여자는 그룹에서 나간 뒤 홈으로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 그룹 탈퇴 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +그룹장이 아닌 참여자가 탈퇴를 확정하면 자신의 참여 정보만 삭제되고 홈으로 이동하는지 검증한다. + +## 시나리오 +일반 참여자가 그룹 상세에서 엔빵 나가기를 확정한다. + +## Given +- 그룹장과 일반 참여자 계정이 같은 그룹에 참여하고 있다. +- 일반 참여자 세션을 주입했다. +- 그룹 상세에 진입했다. + +## When +- 엔빵 나가기를 누른다. +- 나가기 확인 창에서 탈퇴를 확정한다. + +## Then +- 엔빵 나가기 성공 토스트가 표시된다. +- `/home`으로 대체 이동한다. +- 일반 참여자의 나의 엔빵 목록에 해당 그룹이 표시되지 않는다. +- 그룹 자체와 그룹장의 참여 정보는 유지된다. + +## 테스트 데이터 +- 그룹장 1명과 일반 참여자 1명이 속한 그룹 + +## 데이터 준비 방식 상세 +두 계정, 그룹, 참여자와 현재 회차 기록을 Seed로 만든 뒤 일반 참여자의 세션을 주입한다. + +## Cleanup 대상 +- 남아 있는 그룹, 그룹장 참여자, 그룹 기록, 테스트 계정 데이터 + +## 예외/주의사항 +탈퇴 요청 실패 흐름은 코드가 성공 토스트 함수를 호출하므로 기대 문구 확인 전까지 별도 자동화 케이스로 만들지 않는다. + +--- + +### GROUP-CALENDAR-001: 날짜를 선택하면 해당 날짜와 관련된 그룹만 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 캘린더 그룹 필터 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +캘린더에서 날짜를 선택했을 때 시작일, 종료일 또는 결제일이 같은 참여 그룹만 카드로 표시되는지 검증한다. + +## 시나리오 +여러 날짜의 그룹에 참여한 사용자가 캘린더에서 특정 날짜를 선택한다. + +## Given +- 로그인 사용자 세션을 주입했다. +- 선택 날짜가 시작일인 그룹, 종료일인 그룹, 결제일인 그룹과 무관한 날짜의 그룹을 준비했다. +- `/calendar`에 진입했다. + +## When +- 대상 연월로 이동한다. +- 대상 날짜를 누른다. + +## Then +- 시작일, 종료일 또는 결제일이 선택 날짜와 같은 세 그룹 카드가 표시된다. +- 세 날짜가 모두 다른 그룹 카드는 표시되지 않는다. +- 표시된 카드를 누르면 해당 `/nbread/{그룹 아이디}`로 이동한다. + +## 테스트 데이터 +- 동일한 선택 날짜를 각각 `startDate`, `endDate`, `paymentDate`로 가진 그룹 세 개 +- 선택 날짜와 모든 날짜가 다른 그룹 한 개 + +## 데이터 준비 방식 상세 +사용자, 그룹 네 개, 참여자와 필요한 그룹 기록을 Seed로 준비한다. 브라우저 시간대는 서비스 기준 시간대로 고정한다. + +## Cleanup 대상 +- 생성한 그룹, 참여자, 그룹 기록 데이터 + +## 예외/주의사항 +그룹 카드의 참여자 아바타와 완료 상태는 캘린더에서 숨기므로 검증 대상이 아니다. + +--- + +### GROUP-CALENDAR-002: 이번 달과 전체 목록에 함께 속한 그룹은 캘린더에 한 번만 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 그룹 | +| 시나리오 | 캘린더 그룹 중복 제거 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +같은 그룹이 이번 달 목록과 나의 전체 목록 양쪽에서 조회되어도 캘린더에 중복 렌더링되지 않는지 검증한다. + +## 시나리오 +매월 그룹에 참여한 사용자가 그 그룹의 관련 날짜를 캘린더에서 선택한다. + +## Given +- 로그인 사용자가 매월 결제 그룹에 참여하고 있다. +- 그룹의 날짜 중 하나가 캘린더에서 선택할 날짜와 같다. +- `/calendar`에 진입했다. + +## When +- 해당 날짜를 누른다. + +## Then +- 대상 그룹 카드가 정확히 한 개 표시된다. + +## 테스트 데이터 +- 매월 결제 그룹 1개 +- 로그인 사용자의 참여자 정보 +- 선택 대상 날짜 + +## 데이터 준비 방식 상세 +이번 달 엔빵과 나의 엔빵 조회 결과 양쪽에 포함되는 매월 그룹을 Seed로 준비하고 사용자 세션을 주입한다. + +## Cleanup 대상 +- 생성한 그룹, 참여자, 그룹 기록 데이터 + +## 예외/주의사항 +중복 제거 키는 그룹 아이디다. 같은 제목의 서로 다른 그룹은 각각 표시되는 것이 정상이다. diff --git a/llm-wiki/output/2026-08-14-e2e-tc-draft-invite.md b/llm-wiki/output/2026-08-14-e2e-tc-draft-invite.md new file mode 100644 index 0000000..96876b3 --- /dev/null +++ b/llm-wiki/output/2026-08-14-e2e-tc-draft-invite.md @@ -0,0 +1,685 @@ +# 초대 도메인 E2E 테스트 케이스 초안 + +## 조사한 코드 +- `src/app/invite/[token]/page.tsx` +- `src/app/invites/page.tsx` +- `src/components/invite/InviteBottomSheet.tsx` +- `src/components/invite/InviteNoticeModal.tsx` +- `src/components/invite/InvitePageClient.tsx` +- `src/components/invite/InviteResponseModal.tsx` +- `src/components/invite/InviteUserListItem.tsx` +- `src/lib/invite/getInviteByToken.ts` +- `src/lib/invite/getInviteUser.ts` +- `src/lib/invite/getPendingInvites.ts` +- `src/lib/invite/respondToInvite.ts` +- `src/lib/invite/sendInviteRequest.ts` +- `supabase/migrations/20260606073032_unify_nbread_invite_creation.sql` +- `supabase/migrations/20260606073739_add_nbread_invite_indexes.sql` +- `supabase/migrations/20260606074956_respond_to_nbread_invite.sql` +- `supabase/migrations/20260606094345_connect_link_invite_user.sql` +- `supabase/migrations/20260609080033_enforce_nbread_invite_status_policy.sql` +- `supabase/migrations/20260609082516_prevent_duplicate_nbread_participation.sql` +- `supabase/migrations/20260702083718_secure_invite_response_rpc.sql` + +## 확인 필요 사항 +- 비로그인 상태의 `/invites` 접근을 상위 미들웨어나 레이아웃에서 막는지 조사 범위만으로는 알 수 없다. 현재 페이지 코드만 보면 사용자 식별자가 없을 때 로딩이 끝나지 않는다. +- `getInviteUser`는 `nbread_records`의 조회 결과 객체를 문자열 `accept`와 비교한다. 실제 참여 중 사용자가 검색 결과에서 `참여 중`으로 표시되는지는 반환 자료 구조와 기획 확인이 필요하다. +- `sendInviteRequest`가 실패를 내부에서 처리하고 `undefined`를 반환해도 `InviteUserListItem`은 화면 문구를 `요청 완료`로 바꾼다. 실패 시 화면 정책을 확인해야 하므로 성공 케이스와 합치지 않았다. +- 링크 초대의 `target_user_id`가 비어 있을 때 거절하면 대상 계정을 연결하지 않은 채 상태만 `rejected`로 바뀐다. 이것이 의도한 정책인지 확인이 필요하다. +- 정원 초과 수락은 데이터베이스에서 `INVITE_EXPIRED`를 반환하지만 초대 상태 자체를 `expired`로 갱신하지 않는다. 이후 다시 열었을 때 계속 `pending`으로 보이는 현재 동작이 의도인지 확인이 필요하다. +- 초대 조회와 받은 초대 목록에 필요한 공개 조회 및 행 단위 보안 정책은 지정된 마이그레이션에 포함되지 않아, 배포 환경에서 비로그인 초대 조회가 허용되는지는 별도 확인이 필요하다. + +## 케이스 목록 + +### INVITE-DETAIL-001: 유효한 대기 중 초대 링크에서 초대 정보를 확인할 수 있어요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 초대 상세 조회 | +| 케이스 유형 | Smoke | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +유효한 토큰으로 대기 중인 초대를 열면 초대 주체와 엔빵 정보, 응답 버튼이 표시되는지 검증한다. + +## 시나리오 +로그인한 초대 대상자가 대기 중인 초대 링크를 연다. + +## Given +- 로그인 사용자와 해당 사용자를 `target_user_id`로 가진 `pending` 초대가 있다. +- 초대가 가리키는 엔빵과 방장 사용자 자료가 있다. + +## When +- 세션을 주입하고 `/invite/{invite_token}`에 접속한다. + +## Then +- 방장 이름과 엔빵 제목을 포함한 초대 문구가 보인다. +- `초대 수락하기`와 `거절하기` 버튼이 보인다. + +## 테스트 데이터 +- 사용자 1명, 방장 1명, 엔빵 1개, `pending` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 관계 자료를 만든 뒤 초대 대상자의 Supabase 세션을 브라우저에 주입한다. + +## Cleanup 대상 +- 생성한 초대, 엔빵, 사용자 자료를 삭제한다. + +## 예외/주의사항 +- 외부 로그인 제공자 화면은 거치지 않는다. + +--- + +### INVITE-DETAIL-002: 존재하지 않는 초대 링크에서는 찾을 수 없다는 안내가 보여요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 잘못된 초대 링크 조회 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +토큰에 해당하는 초대가 없을 때 오류 화면과 안전한 이동 경로를 제공하는지 검증한다. + +## 시나리오 +사용자가 존재하지 않는 초대 토큰으로 접속한다. + +## Given +- 입력할 토큰과 일치하는 `nbread_invite` 자료가 없다. + +## When +- `/invite/{존재하지-않는-토큰}`에 접속한다. + +## Then +- `초대 정보를 찾을 수 없어요.`와 링크 확인 안내가 보인다. +- `홈으로 가기`를 누르면 `/`로 이동한다. + +## 테스트 데이터 +- 충돌 가능성이 없는 임의 토큰 문자열 + +## 데이터 준비 방식 상세 +- 별도 자료를 만들지 않고 존재하지 않는 토큰을 사용한다. + +## Cleanup 대상 +- 없다. + +## 예외/주의사항 +- 초대 조회 요청 자체가 실패한 경우도 같은 화면으로 합쳐지므로 화면 결과만 검증한다. + +--- + +### INVITE-AUTH-001: 비로그인 사용자는 초대에 응답하기 전에 로그인 안내를 받아요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 비로그인 초대 응답 | +| 케이스 유형 | 권한 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 비로그인 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +비로그인 사용자가 초대 수락이나 거절을 바로 실행하지 못하고 로그인 흐름으로 안내되는지 검증한다. + +## 시나리오 +세션이 없는 사용자가 대기 중 초대 링크를 열고 응답을 시도한다. + +## Given +- 대상 사용자가 연결된 `pending` 초대가 있다. +- 브라우저에 인증 세션이 없다. + +## When +- 초대 링크를 열고 로그인 안내 모달의 로그인 진행 버튼을 누른다. + +## Then +- 로그인 안내 모달이 표시된다. +- `/login?redirect=%2Finvite%2F{token}` 경로로 이동한다. +- 초대 상태와 참여자 자료는 바뀌지 않는다. + +## 테스트 데이터 +- 엔빵 1개와 `pending` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 초대 자료만 만들고 브라우저 저장 상태를 비운 채 시작한다. + +## Cleanup 대상 +- 생성한 초대와 엔빵 자료를 삭제한다. + +## 예외/주의사항 +- 실제 소셜 로그인 화면은 검증하지 않는다. + +--- + +### INVITE-ACCEPT-001: 초대 대상자가 수락하면 엔빵 참여가 완료돼요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 초대 수락 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +대상 사용자의 초대 수락이 참여자 생성과 초대 상태 변경으로 원자적으로 반영되는지 검증한다. + +## 시나리오 +초대 대상자가 확인 모달에서 수락을 확정한다. + +## Given +- 정원이 남은 엔빵과 대상 사용자의 `pending` 초대가 있다. +- 대상 사용자는 아직 해당 엔빵의 참여자가 아니다. + +## When +- 대상 사용자 세션으로 초대 페이지를 연다. +- `초대 수락하기`를 누르고 확인 모달에서 `수락하기`를 누른다. + +## Then +- 처리 중에는 모달 버튼이 비활성화되고 제출 문구가 `처리 중`으로 바뀐다. +- 성공 알림 `엔빵 참여가 완료됐어요.`가 보인다. +- `/nbread/{nbread_id}`로 이동한다. +- 초대 상태는 `accepted`이고 참여자 자료는 정확히 1개다. + +## 테스트 데이터 +- 정원 2명 이상인 엔빵 1개, 방장 참여자 1명, 대상 사용자 1명, `pending` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 자료를 만들고 대상 사용자 세션을 주입한다. + +## Cleanup 대상 +- 생성된 참여자, 초대, 엔빵, 사용자 자료를 삭제한다. + +## 예외/주의사항 +- 경로 이동 전 알림이 짧게 노출될 수 있으므로 알림과 최종 주소를 각각 안정적으로 기다린다. + +--- + +### INVITE-REJECT-001: 초대 대상자가 거절하면 같은 초대를 다시 수락할 수 없어요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 초대 거절 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +거절 응답이 초대 상태에 반영되고 참여자를 만들지 않으며 완료 안내로 전환되는지 검증한다. + +## 시나리오 +초대 대상자가 확인 모달에서 거절을 확정한다. + +## Given +- 대상 사용자의 `pending` 초대가 있다. + +## When +- 대상 사용자 세션으로 초대 페이지를 연다. +- `거절하기`를 누르고 확인 모달에서 `거절하기`를 누른다. + +## Then +- 성공 알림 `엔빵 초대를 거절했어요.`가 보인다. +- 화면에 `이미 거절한 초대예요.`와 `이 초대는 다시 수락할 수 없어요.`가 보인다. +- 초대 상태는 `rejected`이고 해당 사용자의 참여자 자료는 없다. + +## 테스트 데이터 +- 엔빵 1개, 대상 사용자 1명, `pending` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 자료를 만들고 대상 사용자 세션을 주입한다. + +## Cleanup 대상 +- 생성한 초대, 엔빵, 사용자 자료를 삭제한다. + +## 예외/주의사항 +- 거절 확인 모달의 취소 버튼 검증은 이 케이스에 합치지 않는다. + +--- + +### INVITE-AUTH-002: 초대받지 않은 계정은 지정 사용자 초대에 응답할 수 없어요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 초대 대상 계정 검증 | +| 케이스 유형 | 권한 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +초대 토큰이 노출되어도 `target_user_id`와 다른 로그인 사용자가 응답하지 못하는지 검증한다. + +## 시나리오 +초대 대상자가 아닌 계정이 지정 사용자 초대를 수락한다. + +## Given +- 사용자 A를 대상으로 한 `pending` 초대가 있다. +- 사용자 B는 같은 엔빵의 참여자가 아니다. + +## When +- 사용자 B 세션을 주입해 초대 페이지를 연다. +- 수락 확인 모달에서 `수락하기`를 누른다. + +## Then +- `초대받은 계정으로 로그인해 주세요.` 오류 알림이 보인다. +- 확인 모달이 닫힌다. +- 초대는 `pending`으로 유지되고 사용자 B의 참여자 자료는 생성되지 않는다. + +## 테스트 데이터 +- 초대 대상 사용자 A, 권한 없는 사용자 B, 엔빵 1개, `pending` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 두 계정과 초대를 만들고 사용자 B의 세션을 주입한다. + +## Cleanup 대상 +- 생성한 초대, 엔빵, 두 사용자 자료를 삭제한다. + +## 예외/주의사항 +- 데이터베이스 함수의 `INVITE_TARGET_MISMATCH` 분기와 화면 오류 문구를 함께 검증한다. + +--- + +### INVITE-ACCEPT-002: 이미 참여 중인 사용자가 다른 초대를 수락해도 참여자가 중복되지 않아요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 중복 참여 방지 | +| 케이스 유형 | 회귀 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +이미 참여자인 사용자의 추가 초대를 처리할 때 고유 제약을 지키고 기존 엔빵으로 안내하는지 검증한다. + +## 시나리오 +이미 참여 중인 사용자가 같은 엔빵의 별도 대기 초대를 수락한다. + +## Given +- 사용자는 대상 엔빵의 참여자로 등록되어 있다. +- 같은 사용자를 대상으로 한 별도 `pending` 초대가 있다. + +## When +- 사용자 세션으로 초대를 열고 수락을 확정한다. + +## Then +- `이미 참여 중인 엔빵이에요.` 안내 모달이 보인다. +- `엔빵 확인하기`를 누르면 `/nbread/{nbread_id}`로 이동한다. +- 해당 엔빵과 사용자의 참여자 자료는 1개로 유지된다. +- 처리한 초대 상태는 `accepted`다. + +## 테스트 데이터 +- 엔빵 1개, 기존 일반 참여자 1명, 그 참여자를 대상으로 한 `pending` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 기존 참여 관계와 추가 초대를 만들고 참여자 세션을 주입한다. + +## Cleanup 대상 +- 생성한 초대, 참여자, 엔빵, 사용자 자료를 삭제한다. + +## 예외/주의사항 +- `participant_nbread_user_key`와 응답 결과 `already_participant` 분기의 회귀를 함께 확인한다. + +--- + +### INVITE-ACCEPT-003: 정원이 찬 엔빵의 초대를 수락하면 만료 안내가 보여요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 정원 초과 초대 수락 | +| 케이스 유형 | 예외 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +정원이 모두 찬 뒤 도착한 수락 요청이 참여자를 추가하지 않고 만료 안내로 처리되는지 검증한다. + +## 시나리오 +초대 대상자가 정원이 찬 엔빵의 대기 초대를 수락한다. + +## Given +- 엔빵의 현재 참여자 수가 `participant_count`와 같다. +- 아직 참여자가 아닌 대상 사용자의 `pending` 초대가 있다. + +## When +- 대상 사용자 세션으로 수락을 확정한다. + +## Then +- `이미 만료된 초대예요.` 안내 모달이 보인다. +- `홈으로 가기`를 누르면 `/`로 이동한다. +- 대상 사용자의 참여자 자료는 생성되지 않는다. + +## 테스트 데이터 +- 정원과 참여자 수가 같은 엔빵 1개, 대상 사용자 1명, `pending` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 정원을 모두 채우고 대상 사용자 세션을 주입한다. + +## Cleanup 대상 +- 생성한 초대, 참여자, 엔빵, 사용자 자료를 삭제한다. + +## 예외/주의사항 +- 함수 예외로 거래가 되돌려지므로 초대 상태는 현재 구현상 `pending`으로 남는다. + +--- + +### INVITE-STATUS-001: 이미 수락한 초대 링크에서는 참여 중인 엔빵으로 이동할 수 있어요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 수락 완료 초대 재접속 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +수락 완료 초대를 다시 열었을 때 응답 버튼 대신 상태 안내와 엔빵 이동 버튼이 나오는지 검증한다. + +## 시나리오 +사용자가 `accepted` 상태의 초대 링크를 다시 연다. + +## Given +- 초대 상태가 `accepted`이고 대상 사용자가 엔빵에 참여 중이다. + +## When +- 대상 사용자 세션으로 초대 링크에 접속하고 `엔빵 확인하기`를 누른다. + +## Then +- `이미 수락한 초대예요.`와 참여 중인 엔빵 확인 안내가 보인다. +- `/nbread/{nbread_id}`로 이동한다. +- 수락 및 거절 버튼은 보이지 않는다. + +## 테스트 데이터 +- 엔빵 1개, 참여자 1명, `accepted` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 수락 완료 상태를 만들고 대상 사용자 세션을 주입한다. + +## Cleanup 대상 +- 생성한 초대, 참여자, 엔빵, 사용자 자료를 삭제한다. + +## 예외/주의사항 +- 이 케이스는 응답 함수를 다시 호출하지 않는 화면 분기를 검증한다. + +--- + +### INVITE-STATUS-002: 이미 거절한 초대 링크에서는 홈으로 이동할 수 있어요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 거절 완료 초대 재접속 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +거절 완료 초대를 다시 열었을 때 재응답을 막고 홈 이동을 제공하는지 검증한다. + +## 시나리오 +사용자가 `rejected` 상태의 초대 링크를 다시 연다. + +## Given +- 대상 사용자의 초대 상태가 `rejected`다. + +## When +- 대상 사용자 세션으로 초대 링크에 접속하고 `홈으로 가기`를 누른다. + +## Then +- `이미 거절한 초대예요.`와 다시 수락할 수 없다는 안내가 보인다. +- `/`로 이동하고 응답 버튼은 보이지 않는다. + +## 테스트 데이터 +- 엔빵 1개, 대상 사용자 1명, `rejected` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 거절 완료 상태를 만들고 대상 사용자 세션을 주입한다. + +## Cleanup 대상 +- 생성한 초대, 엔빵, 사용자 자료를 삭제한다. + +## 예외/주의사항 +- 참여자 자료가 생성되지 않았는지도 확인한다. + +--- + +### INVITE-STATUS-003: 만료된 초대 링크에서는 다시 초대를 요청하라는 안내가 보여요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 만료 초대 재접속 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +명시적으로 만료 처리된 초대에서 응답을 막고 재초대 안내를 제공하는지 검증한다. + +## 시나리오 +사용자가 `expired` 상태의 초대 링크를 연다. + +## Given +- 대상 사용자의 초대 상태가 `expired`다. + +## When +- 대상 사용자 세션으로 초대 링크에 접속한다. + +## Then +- `이미 만료된 초대예요.`와 방장에게 다시 초대를 요청하라는 안내가 보인다. +- 응답 버튼은 보이지 않고 `홈으로 가기`를 누르면 `/`로 이동한다. + +## 테스트 데이터 +- 엔빵 1개, 대상 사용자 1명, `expired` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 만료 상태를 만들고 대상 사용자 세션을 주입한다. + +## Cleanup 대상 +- 생성한 초대, 엔빵, 사용자 자료를 삭제한다. + +## 예외/주의사항 +- `pending`에서 `expired`로의 변경만 허용하는 상태 전이 정책을 따라 자료를 준비한다. + +--- + +### INVITE-LIST-001: 받은 초대 목록에는 대기 중인 초대만 최신순으로 보여요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 받은 초대 목록 조회 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +로그인 사용자의 대기 중 초대만 목록에 최신순으로 표시되고 선택한 토큰 상세로 이동하는지 검증한다. + +## 시나리오 +여러 상태의 초대를 가진 사용자가 받은 초대 목록을 확인한다. + +## Given +- 한 사용자에게 생성 시각이 다른 `pending` 초대 2개가 있다. +- 같은 사용자에게 `accepted`, `rejected`, `expired` 초대가 각각 있다. + +## When +- 사용자 세션을 주입하고 `/invites`에 접속한다. +- 첫 번째 목록 항목을 누른다. + +## Then +- `pending` 초대 2개만 엔빵 제목, 방장 이름, 상대 시각과 함께 보인다. +- 더 최근에 생성된 초대가 먼저 보인다. +- 첫 번째 초대의 `/invite/{invite_token}`으로 이동한다. + +## 테스트 데이터 +- 사용자 1명, 방장이 연결된 엔빵 5개, 상태별 초대 5개 + +## 데이터 준비 방식 상세 +- Seed에서 `created_at`을 서로 다르게 지정하고 사용자 세션을 주입한다. + +## Cleanup 대상 +- 생성한 초대, 엔빵, 방장과 대상 사용자 자료를 삭제한다. + +## 예외/주의사항 +- 상대 시각의 정확한 문구보다 초대 생성 시각 순서를 우선 검증한다. + +--- + +### INVITE-LIST-002: 대기 중인 초대가 없으면 빈 목록 안내가 보여요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 받은 초대 빈 상태 | +| 케이스 유형 | 예외 | +| 우선순위 | P2 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +사용자에게 대기 중인 초대가 없을 때 빈 상태 안내가 표시되는지 검증한다. + +## 시나리오 +대기 중 초대가 없는 사용자가 받은 초대 목록을 연다. + +## Given +- 로그인 사용자에게 `pending` 상태의 초대가 없다. +- 선택적으로 완료 상태 초대만 존재한다. + +## When +- 사용자 세션을 주입하고 `/invites`에 접속한다. + +## Then +- 로딩이 끝난 뒤 `받은 초대가 없어요.`가 보인다. +- `새로운 초대가 오면 이곳에서 확인할 수 있어요.`가 보인다. + +## 테스트 데이터 +- 대기 중 초대가 없는 사용자 1명 + +## 데이터 준비 방식 상세 +- Seed로 사용자를 만들고 해당 사용자의 `pending` 초대는 만들지 않는다. + +## Cleanup 대상 +- 생성한 사용자와 완료 상태 초대가 있다면 함께 삭제한다. + +## 예외/주의사항 +- 비로그인 상태는 페이지 코드에서 로딩이 끝나지 않으므로 이 케이스에 포함하지 않는다. + +--- + +### INVITE-REINVITE-001: 거절된 초대 뒤에는 새 초대를 보낼 수 있어요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 사용자 재초대 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +이전 거절 또는 만료 기록을 보존하면서 새 대기 초대가 생성되는지 검증한다. + +## 시나리오 +로그인 사용자가 과거 초대를 거절한 사용자에게 다시 초대를 보낸다. + +## Given +- 대상 사용자에게 같은 엔빵의 `rejected` 초대가 있다. +- 초대 바텀 시트에서 해당 사용자는 `초대 하기` 상태로 표시된다. + +## When +- 로그인 사용자 세션으로 초대 바텀 시트를 열고 대상 사용자의 `초대 하기`를 누른다. + +## Then +- 화면 상태가 `요청 완료`로 바뀐다. +- 기존 `rejected` 초대는 보존된다. +- 같은 엔빵과 대상 사용자 조합으로 새 `pending` 초대가 1개 생성된다. + +## 테스트 데이터 +- 로그인 사용자와 대상 사용자 각 1명, 엔빵 1개, 기존 `rejected` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 이전 거절 기록을 만든 뒤 로그인 사용자 세션을 주입한다. + +## Cleanup 대상 +- 새 초대와 기존 초대, 엔빵, 사용자 자료를 삭제한다. + +## 예외/주의사항 +- 초대 바텀 시트를 여는 상위 페이지의 선택자와 진입 경로는 자동화 구현 전에 실제 호출 위치를 추가 조사해야 한다. + +--- + +### INVITE-DUPLICATE-001: 대기 중이거나 수락된 초대가 있으면 중복 초대가 생기지 않아요 +| 속성 | 값 | +|---|---| +| 도메인 | 초대 | +| 시나리오 | 중복 초대 방지 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +처리 중이거나 이미 수락된 초대가 있는 사용자에게 중복 초대 자료가 생성되지 않는지 검증한다. + +## 시나리오 +로그인 사용자가 이미 대기 중인 초대가 있는 사용자의 상태 영역을 누른다. + +## Given +- 같은 엔빵과 대상 사용자 조합의 `pending` 초대가 1개 있다. +- 대상 사용자는 초대 목록에서 `초대 완료` 상태로 표시된다. + +## When +- 로그인 사용자 세션으로 초대 바텀 시트를 열고 해당 사용자의 상태 영역을 누른다. + +## Then +- 추가 `nbread_invite` 자료가 생성되지 않는다. +- 기존 `pending` 초대 토큰과 상태가 유지된다. + +## 테스트 데이터 +- 로그인 사용자와 대상 사용자 각 1명, 엔빵 1개, 기존 `pending` 초대 1개 + +## 데이터 준비 방식 상세 +- Seed로 기존 대기 초대를 만들고 로그인 사용자 세션을 주입한다. + +## Cleanup 대상 +- 생성한 초대, 엔빵, 사용자 자료를 삭제한다. + +## 예외/주의사항 +- 화면 코드는 `초대 완료` 상태에서 전송 함수를 호출하지 않는다. 수락 상태는 화면 표시 경로가 불명확해 별도 케이스로 만들지 않았다. diff --git a/llm-wiki/output/2026-08-14-e2e-tc-draft-landing.md b/llm-wiki/output/2026-08-14-e2e-tc-draft-landing.md new file mode 100644 index 0000000..83f296e --- /dev/null +++ b/llm-wiki/output/2026-08-14-e2e-tc-draft-landing.md @@ -0,0 +1,700 @@ +# 랜딩페이지 도메인 E2E 테스트 케이스 초안 + +## 조사한 코드 +- `src/app/page.tsx` +- `src/components/landing/RevealOnScroll.tsx` +- `src/components/seo/JsonLdScript.tsx` +- `src/lib/seo.ts` +- `src/lib/jsonLd.ts` +- `src/app/ios-guide/page.tsx` +- `src/app/manifest.json` +- `public/robots.txt` +- `public/sitemap.xml` +- `src/app/layout.tsx` — 절대 주소 기준, 공통 메타데이터, 매니페스트 연결을 확인하기 위해 참고함 +- `src/app/protectRoute.tsx` — 랜딩페이지와 iOS 안내 페이지의 공개 경로 여부를 확인하기 위해 참고함 +- `src/components/common/header/DetailHeader.tsx` — iOS 안내 페이지의 뒤로 가기 동작을 확인하기 위해 참고함 +- `public/image/landing/home.png` 및 `public/image/ios-guide/step2.png`~`step5.png` — 화면에서 참조하는 이미지 파일의 존재를 확인함 +- `public/assets/logo/open-graph-logo.png`, `public/assets/logo/nbread-logo.png` — 검색 최적화 데이터가 참조하는 이미지 파일의 존재를 확인함 +- `public/pwa-icons/icon512_maskable.png`, `public/pwa-icons/icon512_rounded.png`, `public/screenshots/home_wide.png`, `public/screenshots/home_mobile.png` — 매니페스트가 참조하는 파일의 존재를 확인함 + +## 확인 필요 사항 +- 랜딩페이지는 모바일 폭을 중심으로 스타일이 작성되어 있으나 지원해야 하는 최소·최대 화면 폭과 데스크톱 레이아웃의 디자인 기준은 코드만으로 확정할 수 없다. +- `robots.txt`는 `/ios-guide`를 허용하지만 `sitemap.xml`은 사이트맵 색인 파일만 가리킨다. 실제 `sitemap-0.xml`에 랜딩페이지와 iOS 안내 페이지가 포함되어야 하는지는 배포 산출물과 검색 노출 정책 확인이 필요하다. +- iOS 안내 페이지의 실제 홈 화면 추가와 알림 허용 과정은 운영체제와 Safari가 제공하는 화면이므로 웹 Playwright 자동화 범위에 포함할지 별도 결정이 필요하다. +- 랜딩페이지의 세 가지 시작 버튼에 분석 이벤트가 필요한지는 현재 조사 범위의 코드에서 확인되지 않는다. +- iOS 안내 페이지의 뒤로 가기 버튼은 접근 가능한 이름과 버튼 역할이 없는 `div`로 구현되어 있다. 키보드 조작 지원을 요구하는지 확인이 필요하다. +- `RevealOnScroll`이 화면 밖 요소를 관찰하기 전에는 투명하게 렌더링한다. 자바스크립트가 완전히 꺼진 환경에서도 내용을 보여야 하는지는 확인이 필요하다. + +## 케이스 목록 + +### LANDING-MAIN-001: 비로그인 사용자가 랜딩페이지의 핵심 소개 내용을 볼 수 있다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 랜딩페이지 조회 | +| 케이스 유형 | 권한 | +| 우선순위 | P0 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +인증 정보가 없는 사용자도 공개 경로인 `/`에 접근하여 서비스의 핵심 설명을 확인할 수 있는지 검증한다. + +## 시나리오 +비로그인 사용자가 랜딩페이지에 접속해 대표 제목과 주요 기능 소개를 확인한다. + +## Given +- 브라우저에 엔빵 로그인 세션과 저장된 사용자 정보가 없다. + +## When +- 사용자가 `/`에 접속한다. + +## Then +- 다른 경로로 이동하지 않고 `/`가 표시된다. +- `구독 공유, 헷갈리게 쓰지 말고 엔빵으로 딱 정리` 제목을 볼 수 있다. +- `그룹 관리`, `간편 초대`, `정산 추적`, `채팅 및 공지`, `주요 알림` 기능 제목을 모두 볼 수 있다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- 새 브라우저 컨텍스트를 사용하고 쿠키와 로컬 저장소를 주입하지 않는다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 화면 아래쪽 기능은 스크롤한 뒤 검증한다. +- `ProtectRoute`의 공개 경로 목록에 `/`가 포함된 구현을 근거로 한다. + +--- + +### LANDING-CTA-001: 상단 시작하기 버튼을 누르면 로그인 페이지로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 로그인 시작 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +랜딩페이지 머리글의 주요 전환 버튼이 로그인 흐름으로 연결되는지 검증한다. + +## 시나리오 +비로그인 사용자가 머리글의 시작하기 버튼으로 로그인을 시작한다. + +## Given +- 비로그인 사용자가 `/`에 접속해 있다. + +## When +- 머리글의 `시작하기` 링크를 누른다. + +## Then +- 현재 주소가 `/login`으로 변경된다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- 별도 데이터 없이 새 브라우저 컨텍스트에서 시작한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 소셜 로그인 제공자 화면으로는 진입하지 않는다. +- 같은 이름의 다른 버튼과 구분하기 위해 머리글 내부 링크를 선택한다. + +--- + +### LANDING-CTA-002: 본문의 지금 시작하기 버튼들이 모두 로그인 페이지로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 본문에서 로그인 시작 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +첫 화면과 페이지 마지막에 반복 배치된 전환 링크가 모두 동일한 로그인 경로를 유지하는지 검증한다. + +## 시나리오 +사용자가 랜딩페이지의 각 지금 시작하기 링크로 로그인 페이지에 진입한다. + +## Given +- 비로그인 사용자가 `/`에 접속해 있다. + +## When +- 첫 화면의 `지금 시작하기` 링크를 누른다. +- 새로 `/`에 접속한 뒤 페이지 마지막의 `지금 시작하기` 링크를 누른다. + +## Then +- 각 링크를 누른 뒤 현재 주소가 `/login`이다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- 각 링크 검증 전에 `/`로 이동하여 독립된 시작 상태를 만든다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 하나의 테스트 안에서 두 링크를 각각 검증하되, 어느 링크에서 실패했는지 단계 이름으로 구분한다. +- 소셜 로그인 버튼은 누르지 않는다. + +--- + +### LANDING-CONTENT-001: 랜딩페이지가 문제와 해결 방법과 사용 순서를 빠짐없이 안내한다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 서비스 소개 확인 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +배열 순회로 렌더링되는 랜딩페이지의 핵심 콘텐츠가 누락되거나 순서가 바뀌지 않는지 검증한다. + +## 시나리오 +사용자가 페이지를 아래로 스크롤하며 서비스가 해결하는 문제와 사용 방법을 확인한다. + +## Given +- 사용자가 `/`에 접속해 있다. + +## When +- 사용자가 페이지 끝까지 스크롤한다. + +## Then +- 문제 카드 3개가 `어디서 얼마 내는지 기억이 안 나요`, `결제일을 깜빡해서 구독 취소된 적 있어요`, `누가 얼마 보냈는지 일일이 확인해야 해요` 순서로 보인다. +- 해결 항목 3개가 `그룹 단위 관리`, `1/N 정산 계산기`, `정산 현황 추적` 순서로 보인다. +- 사용 순서가 `STEP 1`부터 `STEP 3`까지 표시되고 제목이 각각 `그룹 만들기`, `멤버 초대하기`, `정산 현황 확인`이다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- 정적 페이지를 직접 조회한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 문구 전체의 픽셀 단위 비교 대신 제목, 개수, 문서 순서를 검증한다. + +--- + +### LANDING-MEDIA-001: 랜딩페이지의 홈 화면 미리보기가 대체 문구와 함께 정상 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 대표 이미지 조회 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +서비스 첫인상을 구성하는 대표 이미지의 경로와 접근성 문구가 유지되는지 검증한다. + +## 시나리오 +사용자가 랜딩페이지에서 엔빵 홈 화면 미리보기를 확인한다. + +## Given +- 사용자가 `/`에 접속해 있다. + +## When +- `엔빵 홈 화면 미리보기` 이미지를 찾는다. + +## Then +- 이미지가 문서에 존재하고 화면에 표시된다. +- 이미지의 자연 너비와 자연 높이가 0보다 커서 깨진 이미지가 아니다. +- 대체 문구가 `엔빵 홈 화면 미리보기`이다. + +## 테스트 데이터 +- `public/image/landing/home.png` + +## 데이터 준비 방식 상세 +- 저장소에 포함된 정적 이미지를 애플리케이션이 제공하는 상태로 시작한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- `next/image`가 변환한 실제 요청 주소는 실행 환경에 따라 달라질 수 있으므로 `src` 문자열 전체를 고정하지 않는다. + +--- + +### LANDING-MOTION-001: 스크롤한 영역의 콘텐츠가 관찰된 뒤 화면에 나타난다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 스크롤 등장 효과 | +| 케이스 유형 | 성공 | +| 우선순위 | P2 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +교차 관찰자가 화면에 진입한 콘텐츠를 한 번 표시한 뒤 다시 숨기지 않는지 검증한다. + +## 시나리오 +사용자가 랜딩페이지를 아래로 스크롤해 등장 효과가 적용된 영역을 본다. + +## Given +- 브라우저가 `IntersectionObserver`를 지원한다. +- 사용자가 `/`에 접속해 있다. + +## When +- `핵심 기능` 영역이 화면 안에 들어오도록 스크롤한다. +- 등장 전환 시간이 끝날 때까지 기다린다. +- 다시 위아래로 스크롤하여 해당 영역을 화면 밖으로 보냈다가 돌아온다. + +## Then +- `핵심 기능` 영역이 `opacity-100`과 `translate-y-0` 상태가 된다. +- 화면 밖으로 나갔다 돌아와도 해당 영역은 표시된 상태를 유지한다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- 실제 브라우저의 교차 관찰자를 사용한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 구현의 전환 시간이 700밀리초이므로 즉시 단언하지 않고 조건이 충족될 때까지 기다린다. +- 지연 시간 자체의 정밀한 시간 측정은 환경 편차가 커서 검증하지 않는다. + +--- + +### LANDING-MOTION-002: 교차 관찰자를 지원하지 않는 브라우저에서도 랜딩 콘텐츠가 숨지 않는다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 스크롤 효과 대체 동작 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +`IntersectionObserver`가 없는 환경에서 대체 분기가 콘텐츠를 즉시 표시하는지 검증한다. + +## 시나리오 +교차 관찰자를 지원하지 않는 브라우저로 랜딩페이지를 연다. + +## Given +- 페이지 스크립트 실행 전에 `window.IntersectionObserver`를 제거한다. +- 로그인 세션은 없다. + +## When +- `/`에 접속한다. + +## Then +- 등장 효과가 적용된 요소들이 `opacity-100`과 `translate-y-0` 상태가 된다. +- 페이지 끝의 `정산 스트레스에서 벗어나세요` 문구까지 스크롤하여 볼 수 있다. +- 처리되지 않은 페이지 오류가 발생하지 않는다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- Playwright의 문서 생성 전 초기화 스크립트로 `IntersectionObserver`를 사용할 수 없는 환경을 만든다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 전역 객체 변경이 다른 테스트에 전파되지 않도록 이 케이스 전용 브라우저 컨텍스트를 사용한다. + +--- + +### LANDING-MOTION-003: 모션 축소를 설정한 사용자는 이동과 전환 없이 콘텐츠를 볼 수 있다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 모션 축소 대응 | +| 케이스 유형 | 예외 | +| 우선순위 | P2 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +운영체제의 모션 축소 설정을 반영하는 스타일이 등장 효과를 제거하는지 검증한다. + +## 시나리오 +모션 축소를 선호하는 사용자가 랜딩페이지를 조회한다. + +## Given +- 브라우저 미디어 설정의 `reducedMotion`을 `reduce`로 설정한다. + +## When +- `/`에 접속하고 등장 효과가 적용된 요소를 확인한다. + +## Then +- 요소의 계산된 투명도는 `1`이다. +- 요소의 계산된 변형은 이동이 없는 값이다. +- 전환 지속 시간은 `0s`이다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- Playwright 브라우저 컨텍스트의 미디어 기능 모의 설정을 사용한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- `motion-reduce:translate-y-0`, `motion-reduce:opacity-100`, `motion-reduce:transition-none` 클래스의 실제 계산 스타일을 검증한다. + +--- + +### LANDING-SEO-001: 랜딩페이지가 검색과 공유에 필요한 메타데이터를 제공한다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 랜딩 검색 메타데이터 확인 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +랜딩페이지의 검색 결과 및 사회관계망 공유 정보가 코드에 정의된 값으로 출력되는지 검증한다. + +## 시나리오 +검색 봇 또는 공유 미리보기 수집기가 랜딩페이지의 머리말 정보를 읽는다. + +## Given +- 애플리케이션이 `https://www.nbread.co.kr`을 메타데이터 기준 주소로 사용한다. + +## When +- `/`의 문서 머리말을 조회한다. + +## Then +- 문서 제목은 `엔빵`이다. +- 설명은 `친구와 가족과 나누는 구독 서비스의 결제일과 정산 현황을 한 곳에서 관리하는 구독 공유 관리 서비스`이다. +- 표준 주소는 `https://www.nbread.co.kr/`이다. +- 오픈 그래프 제목은 `엔빵`, 지역은 `ko_KR`, 유형은 `website`이다. +- 트위터 카드 유형은 `summary_large_image`이다. +- 오픈 그래프 이미지는 절대 주소로 해석되며 자연 너비와 자연 높이가 0보다 크다. + +## 테스트 데이터 +- 기준 사이트 주소 `https://www.nbread.co.kr` +- 오픈 그래프 이미지 `/assets/logo/open-graph-logo.png` + +## 데이터 준비 방식 상세 +- 정적 메타데이터가 포함된 서버 응답을 조회한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 실제 테스트 서버의 호스트와 무관하게 `metadataBase`로 생성되는 공개 주소를 기대한다. + +--- + +### LANDING-SEO-002: 랜딩페이지가 유효한 구조화 데이터를 한 개의 스크립트로 제공한다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 랜딩 구조화 데이터 확인 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +검색 엔진이 엔빵의 조직, 웹사이트, 웹 애플리케이션 정보를 구조화된 형식으로 읽을 수 있는지 검증한다. + +## 시나리오 +검색 수집기가 랜딩페이지의 JSON-LD 스크립트를 읽고 해석한다. + +## Given +- 사용자가 `/`에 접속해 있다. + +## When +- `application/ld+json` 유형의 스크립트를 읽고 JSON으로 해석한다. + +## Then +- 해당 유형의 스크립트가 정확히 1개 존재하고 JSON 해석에 성공한다. +- `@context`는 `https://schema.org`이다. +- `@graph`에는 `Organization`, `WebSite`, `WebApplication` 항목이 각각 1개 있다. +- 세 항목의 이름과 주소는 각각 `엔빵`과 `https://www.nbread.co.kr`이다. +- 조직 로고 주소는 `https://www.nbread.co.kr/assets/logo/nbread-logo.png`이다. +- 웹사이트와 웹 애플리케이션의 언어는 `ko-KR`이다. +- 웹 애플리케이션의 분류는 `UtilitiesApplication`, 운영체제는 `Web`이다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- 페이지에 출력된 스크립트의 `textContent`를 JSON으로 변환하여 속성을 확인한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- JSON 문자열의 공백이나 속성 순서에 의존하지 않는다. + +--- + +### LANDING-ROBOTS-001: 검색 봇은 랜딩페이지를 수집할 수 있고 내부 서비스 경로는 수집하지 못한다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 검색 봇 접근 제어 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 권한 없음 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +검색 봇의 내부 서비스 경로 수집 시도는 거부하면서 공개 랜딩페이지는 수집하도록 한 규칙을 검증한다. + +## 시나리오 +검색 봇이 루트와 인증 뒤 내부 경로의 수집 가능 여부를 판단한다. + +## Given +- 애플리케이션의 `/robots.txt`를 조회할 수 있다. + +## When +- 모든 사용자 에이전트에 적용되는 허용 및 거부 규칙을 해석한다. + +## Then +- `/`는 허용된다. +- `/auth/`, `/calendar`, `/friendList`, `/home`, `/invites`, `/mypage`, `/nbread/`, `/notification`, `/terms-agreement`에 대한 수집 시도는 거부된다. +- 호스트는 `https://www.nbread.co.kr`이다. +- 사이트맵 주소는 `https://www.nbread.co.kr/sitemap.xml`이다. + +## 테스트 데이터 +- `public/robots.txt` + +## 데이터 준비 방식 상세 +- `/robots.txt`의 응답 본문을 가져와 줄 단위 규칙을 확인한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 이 케이스의 실패 유형은 검색 봇의 비공개 경로 수집 시도가 의도대로 거부되는 흐름을 뜻한다. +- `robots.txt`는 보안 통제가 아니므로 실제 사용자의 주소 접근 차단을 기대하지 않는다. + +--- + +### LANDING-PWA-001: 웹 앱 매니페스트가 엔빵의 설치 정보를 올바르게 제공한다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | 웹 앱 설치 정보 확인 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +랜딩페이지에서 연결한 웹 앱 매니페스트와 설치용 정적 자원이 유효한지 검증한다. + +## 시나리오 +브라우저가 랜딩페이지의 매니페스트를 읽어 설치 정보를 구성한다. + +## Given +- 비로그인 사용자가 `/`에 접속해 있다. + +## When +- 문서의 매니페스트 연결을 따라 `/manifest.json`을 요청한다. + +## Then +- 매니페스트 응답을 JSON으로 해석할 수 있다. +- 이름과 짧은 이름은 `엔빵`, 시작 주소와 범위는 `/`이다. +- 표시 방식은 `standalone`, 언어는 `ko-KR`, 방향은 `auto`이다. +- 512x512 크기의 `maskable` 아이콘과 `any` 아이콘이 각각 선언되어 있다. +- `wide`와 `narrow` 형태의 화면 캡처가 각각 선언되어 있다. +- 선언된 아이콘 2개와 화면 캡처 2개의 요청이 모두 성공하고 이미지의 자연 크기가 0보다 크다. + +## 테스트 데이터 +- `/manifest.json` +- `/pwa-icons/icon512_maskable.png` +- `/pwa-icons/icon512_rounded.png` +- `/screenshots/home_wide.png` +- `/screenshots/home_mobile.png` + +## 데이터 준비 방식 상세 +- 애플리케이션이 제공하는 정적 파일을 직접 요청한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 실제 설치 창과 운영체제 홈 화면은 자동화 범위에서 제외한다. + +--- + +### LANDING-IOS-GUIDE-001: 비로그인 사용자가 iOS 홈 화면 추가 안내를 순서대로 볼 수 있다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | iOS 설치 안내 조회 | +| 케이스 유형 | 권한 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +인증 없이 공개된 iOS 안내 페이지에서 홈 화면 추가 절차와 문제 해결 안내를 확인할 수 있는지 검증한다. + +## 시나리오 +비로그인 사용자가 iOS 안내 페이지를 열어 설치 순서와 지원 브라우저 주의사항을 확인한다. + +## Given +- 브라우저에 로그인 세션과 저장된 사용자 정보가 없다. + +## When +- `/ios-guide`에 직접 접속한다. + +## Then +- 랜딩페이지로 이동되지 않고 `/ios-guide`가 표시된다. +- 제목은 `iOS 홈 화면에 추가하기`이다. +- 단계 제목이 1번 `Safari에서 엔빵 접속하기`부터 5번 `엔빵 알림 허용하기`까지 순서대로 표시된다. +- Safari가 아닌 브라우저와 카카오톡 내부 브라우저에 대한 주의 문구가 보인다. +- `홈 화면에 추가가 안 보여요` 문제 해결 영역과 Safari로 다시 여는 3단계가 보인다. + +## 테스트 데이터 +- 없음 + +## 데이터 준비 방식 상세 +- 새 브라우저 컨텍스트에서 `/ios-guide`를 직접 조회한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- `ProtectRoute`의 공개 경로 목록에 `/ios-guide`가 포함된 구현을 근거로 한다. +- 운영체제의 실제 홈 화면 추가 동작은 실행하지 않는다. + +--- + +### LANDING-IOS-GUIDE-002: iOS 안내 단계의 네 개 이미지가 올바른 대체 문구로 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | iOS 설치 안내 이미지 조회 | +| 케이스 유형 | 회귀 | +| 우선순위 | P2 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +이미지가 정의된 iOS 안내 단계에서 정적 이미지 누락과 단계 번호 불일치를 방지한다. + +## 시나리오 +사용자가 iOS 안내 페이지를 스크롤하며 각 단계 이미지를 확인한다. + +## Given +- 사용자가 `/ios-guide`에 접속해 있다. + +## When +- 2단계부터 5단계까지 스크롤한다. + +## Then +- 이미지는 정확히 4개 표시된다. +- 대체 문구는 `2단계 이미지`, `3단계 이미지`, `4단계 이미지`, `5단계 이미지` 순서이다. +- 각 이미지의 자연 너비와 자연 높이가 0보다 크다. +- 1단계에는 단계 이미지가 없다. + +## 테스트 데이터 +- `/image/ios-guide/step2.png` +- `/image/ios-guide/step3.png` +- `/image/ios-guide/step4.png` +- `/image/ios-guide/step5.png` + +## 데이터 준비 방식 상세 +- 저장소에 포함된 정적 이미지를 애플리케이션이 제공하는 상태로 시작한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 반응형 이미지 변환 주소가 아닌 대체 문구와 실제 로드 완료 상태를 검증한다. + +--- + +### LANDING-IOS-GUIDE-003: iOS 안내 페이지의 검색 메타데이터가 랜딩페이지와 구분된다 +| 속성 | 값 | +|---|---| +| 도메인 | 랜딩페이지 | +| 시나리오 | iOS 안내 검색 메타데이터 확인 | +| 케이스 유형 | 성공 | +| 우선순위 | P2 | +| 데이터 준비 방식 | 불필요 | +| 계정 조건 | 비로그인 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +iOS 안내 페이지가 고유한 제목, 설명, 표준 주소를 제공하는지 검증한다. + +## 시나리오 +검색 수집기가 iOS 안내 페이지의 머리말 정보를 읽는다. + +## Given +- 애플리케이션이 `https://www.nbread.co.kr`을 메타데이터 기준 주소로 사용한다. + +## When +- `/ios-guide`의 문서 머리말을 조회한다. + +## Then +- 문서 제목과 오픈 그래프 제목은 `iOS 홈 화면 추가 가이드 | 엔빵`이다. +- 설명은 `iPhone Safari에서 엔빵을 홈 화면에 추가하고 앱처럼 실행하는 방법을 단계별로 안내합니다.`이다. +- 표준 주소와 오픈 그래프 주소는 `https://www.nbread.co.kr/ios-guide`이다. +- 트위터 카드 유형은 `summary_large_image`이다. + +## 테스트 데이터 +- 기준 사이트 주소 `https://www.nbread.co.kr` + +## 데이터 준비 방식 상세 +- 정적 메타데이터가 포함된 서버 응답을 조회한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 제목은 `createPageMetadata`의 기본 동작과 루트 레이아웃의 제목 서식을 함께 적용한 결과를 검증한다. diff --git a/llm-wiki/output/2026-08-14-e2e-tc-draft-mypage.md b/llm-wiki/output/2026-08-14-e2e-tc-draft-mypage.md new file mode 100644 index 0000000..7fef17b --- /dev/null +++ b/llm-wiki/output/2026-08-14-e2e-tc-draft-mypage.md @@ -0,0 +1,292 @@ +# 마이페이지 도메인 E2E 테스트 케이스 초안 + +## 조사한 코드 +- `src/app/mypage/page.tsx` +- `src/app/mypage/notification-setting/page.tsx` +- `src/components/mypage/BasicList.tsx` +- `src/components/mypage/Manage.tsx` +- `src/components/mypage/MenuList.tsx` +- `src/components/mypage/MyInfo.tsx` +- `src/components/user/DeleteAccountModal.tsx` +- `src/components/user/LoginButton.tsx` +- `src/components/user/LogoutModal.tsx` +- `src/components/user/TermsAgreementExitModal.tsx` +- `src/components/user/TermsAgreementForm.tsx` +- `src/types/user.ts` + +## 확인 필요 사항 +- 조사 범위에는 프로필 수정 화면이나 수정 동작이 없어 프로필 수정 테스트 케이스를 작성하지 않았다. +- 조사 범위의 마이페이지에는 비로그인 사용자의 접근을 막거나 다른 화면으로 보내는 코드가 없다. 상위 미들웨어 또는 레이아웃에서 접근을 제한하는지 확인이 필요하다. +- 로그아웃 이후 이동 경로와 로그아웃 실패 처리 방식은 조사 범위 밖의 `logout` 구현에 있으므로 이 문서에서는 확인하지 않는다. +- 알림 상태 조회 및 저장 실패에 대한 화면 내 오류 처리가 없다. 실패 시 기대 화면과 재시도 정책을 확인해야 한다. +- 알림 권한이 `unsupported`이고 `shouldShowIOSGuide`가 참일 때 안내 모달의 열림 상태는 훅에서 관리한다. 대상 기기와 브라우저 기준을 확인해야 한다. +- `BasicList`에서 조회한 전체 알림 상태는 `isToggle`에 저장되지만 화면에 사용되지 않는다. 마이페이지 목록에서 알림 상태를 보여주려는 의도인지 확인이 필요하다. +- 탈퇴 메뉴는 별도 탈퇴 화면으로 이동하지 않고 확인 모달에서 탈퇴 함수를 직접 호출한다. 이번 범위에서는 모달 진입과 취소만 다룬다. +- 알림 설정 화면(`/mypage/notification-setting`)의 토글 동작 자체(조회 반영, 전체/개별 켜기·끄기, 권한 거부·미지원 처리, 사용자 없음 처리)는 `2026-08-14-e2e-tc-draft-notification.md`의 NOTI-SETTINGS-*, NOTI-PERMISSION-001과 중복이라 도메인 간 교차검토 후 제외했다. 마이페이지 도메인에는 진입 네비게이션(MYPAGE-NOTIFICATION-NAV-001)만 남긴다. + +## 케이스 목록 + +### MYPAGE-PROFILE-001: 로그인한 사용자의 프로필 정보가 마이페이지에 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 마이페이지 | +| 시나리오 | 프로필 조회 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +세션에 연결된 사용자의 이름, 소셜 로그인 종류, 이메일, 프로필 이미지가 마이페이지의 내 정보 영역에 표시되는지 검증한다. + +## 시나리오 +사용자 세션을 주입한 뒤 마이페이지를 열어 프로필 정보를 확인한다. + +## Given +- 이름, 이메일, 소셜 로그인 종류, 프로필 이미지가 있는 사용자의 세션이 주입되어 있다. + +## When +- `/mypage`에 접속한다. + +## Then +- `내 정보` 영역에 사용자 이름이 표시된다. +- 소셜 로그인 종류가 대문자로 표시되고 뒤에 `계정`이 표시된다. +- 사용자 이메일과 프로필 이미지가 표시된다. + +## 테스트 데이터 +- 이름: `마이페이지 사용자` +- 이메일: `mypage@example.com` +- 소셜 로그인 종류: `google` +- 프로필 이미지: 접근 가능한 테스트 이미지 주소 + +## 데이터 준비 방식 상세 +Supabase Admin API로 테스트 사용자를 만들고 해당 사용자의 세션을 브라우저에 주입한다. 사용자 스토어가 준비된 뒤 페이지를 연다. + +## Cleanup 대상 +없음. + +## 예외/주의사항 +소셜 로그인 제공자 화면은 열지 않는다. 표시 값은 `User` 타입과 `MyInfo`의 렌더링을 기준으로 검증한다. + +--- + +### MYPAGE-PROFILE-002: 사용자 정보가 준비되지 않으면 기본 문구가 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 마이페이지 | +| 시나리오 | 프로필 빈 상태 표시 | +| 케이스 유형 | 예외 | +| 우선순위 | P2 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 권한 없음 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +사용자 스토어의 사용자가 비어 있는 동안 프로필 영역이 깨지지 않고 코드에 정의된 기본 문구를 표시하는지 검증한다. + +## 시나리오 +사용자 정보가 없는 상태로 마이페이지의 내 정보 영역을 확인한다. + +## Given +- 사용자 스토어의 `user` 값이 없다. + +## When +- `/mypage`를 렌더링한다. + +## Then +- 이름 위치에 `이름 없음`이 표시된다. +- 계정 종류 위치에 `소셜 로그인 계정`이 표시된다. +- 이메일 위치에 `이메일 없음`이 표시된다. +- 프로필 영역 렌더링이 중단되지 않는다. + +## 테스트 데이터 +- 사용자 스토어: `user` 없음 + +## 데이터 준비 방식 상세 +페이지 테스트 환경에서 사용자 스토어를 빈 상태로 고정한다. + +## Cleanup 대상 +없음. + +## 예외/주의사항 +이 케이스는 라우트 접근 정책이 아니라 `MyInfo`에 명시된 빈 값 분기만 검증한다. + +--- + +### MYPAGE-NOTIFICATION-NAV-001: 알림 설정 메뉴를 누르면 알림 설정 화면으로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 마이페이지 | +| 시나리오 | 알림 설정 화면 진입 | +| 케이스 유형 | Smoke | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +마이페이지에서 알림 설정 화면으로 이동하는 핵심 진입 경로를 검증한다. + +## 시나리오 +마이페이지의 기본 메뉴에서 알림 설정을 선택한다. + +## Given +- 로그인한 사용자 세션이 주입되어 있다. +- `/mypage`가 열려 있다. + +## When +- `알림 설정` 메뉴를 누른다. + +## Then +- 주소가 `/mypage/notification-setting`으로 변경된다. +- `알림 설정` 제목과 전체 알림 및 네 개의 개별 알림 토글이 표시된다. + +## 테스트 데이터 +- 알림 설정 레코드가 있는 테스트 사용자 + +## 데이터 준비 방식 상세 +Supabase Admin API로 생성한 사용자의 세션을 주입하고 알림 설정 조회가 완료될 때까지 기다린다. + +## Cleanup 대상 +없음. + +## 예외/주의사항 +알림 상태 값 자체는 별도 케이스에서 검증한다. + +--- + +### MYPAGE-LOGOUT-001: 로그아웃을 취소하면 확인 모달이 닫히고 세션이 유지된다 +| 속성 | 값 | +|---|---| +| 도메인 | 마이페이지 | +| 시나리오 | 로그아웃 취소 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +사용자가 로그아웃 의사를 철회했을 때 로그아웃을 실행하지 않고 마이페이지에 머무는지 검증한다. + +## 시나리오 +로그아웃 확인 모달을 연 뒤 취소한다. + +## Given +- 로그인한 사용자 세션이 주입되어 있다. +- `/mypage`가 열려 있다. + +## When +- `로그아웃` 메뉴를 누른다. +- `로그아웃 하시겠어요?` 모달에서 `취소`를 누른다. + +## Then +- 로그아웃 확인 모달이 닫힌다. +- 마이페이지에 머문다. +- 사용자 프로필 정보가 계속 표시된다. + +## 테스트 데이터 +- 로그인 가능한 테스트 사용자 + +## 데이터 준비 방식 상세 +Supabase Admin API로 만든 세션을 브라우저에 주입한다. + +## Cleanup 대상 +세션이 유지되므로 없음. + +## 예외/주의사항 +실제 소셜 로그인 화면은 사용하지 않는다. + +--- + +### MYPAGE-LOGOUT-002: 로그아웃을 확인하면 처리 중 로딩 화면이 표시된다 +| 속성 | 값 | +|---|---| +| 도메인 | 마이페이지 | +| 시나리오 | 로그아웃 실행 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +로그아웃 확인 시 중복 조작을 막도록 마이페이지가 즉시 로딩 화면으로 전환되는지 검증한다. + +## 시나리오 +로그아웃 확인 모달에서 로그아웃을 실행한다. + +## Given +- 로그인한 사용자 세션이 주입되어 있다. +- 로그아웃 함수의 완료를 테스트에서 지연할 수 있다. + +## When +- `로그아웃` 메뉴를 누른다. +- 확인 모달의 `로그아웃` 버튼을 누른다. + +## Then +- 로그아웃 함수가 호출된다. +- 함수가 처리 중인 동안 마이페이지 내용 대신 로딩 화면이 표시된다. + +## 테스트 데이터 +- 로그인 가능한 테스트 사용자 + +## 데이터 준비 방식 상세 +세션을 주입하고 로그아웃 함수의 응답을 지연시키는 Mock을 사용해 처리 중 화면을 관찰한다. + +## Cleanup 대상 +Mock이 실제 세션을 변경하지 않으므로 없음. + +## 예외/주의사항 +로그아웃 완료 뒤 이동 경로는 조사 범위 밖이므로 이 케이스에서 단정하지 않는다. + +--- + +### MYPAGE-WITHDRAWAL-NAV-001: 탈퇴하기 메뉴를 누르면 탈퇴 확인 모달이 열린다 +| 속성 | 값 | +|---|---| +| 도메인 | 마이페이지 | +| 시나리오 | 탈퇴 확인 화면 진입 | +| 케이스 유형 | Smoke | +| 우선순위 | P1 | +| 데이터 준비 방식 | 세션 주입 | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +마이페이지에서 회원 탈퇴 확인 단계로 진입하고 취소할 수 있는지 검증한다. + +## 시나리오 +탈퇴하기 메뉴로 확인 모달을 연 뒤 취소한다. + +## Given +- 로그인한 사용자 세션이 주입되어 있다. +- `/mypage`가 열려 있다. + +## When +- `탈퇴하기` 메뉴를 누른다. + +## Then +- `정말 탈퇴하시겠어요?` 제목의 모달이 열린다. +- 회원정보 및 엔빵 정보가 삭제된다는 안내와 `취소`, `탈퇴하기` 버튼이 표시된다. +- `취소`를 누르면 모달이 닫히고 마이페이지에 머문다. + +## 테스트 데이터 +- 로그인 가능한 테스트 사용자 + +## 데이터 준비 방식 상세 +Supabase Admin API로 만든 세션을 브라우저에 주입한다. + +## Cleanup 대상 +탈퇴를 실행하지 않으므로 없음. + +## 예외/주의사항 +탈퇴 실행과 완료 결과는 인증 도메인 범위이므로 `탈퇴하기` 확인 버튼은 누르지 않는다. + diff --git a/llm-wiki/output/2026-08-14-e2e-tc-draft-notification.md b/llm-wiki/output/2026-08-14-e2e-tc-draft-notification.md new file mode 100644 index 0000000..0ca0814 --- /dev/null +++ b/llm-wiki/output/2026-08-14-e2e-tc-draft-notification.md @@ -0,0 +1,691 @@ +# 알림 도메인 E2E 테스트 케이스 초안 + +## 조사한 코드 +- `src/app/notification/page.tsx` +- `src/app/mypage/notification-setting/page.tsx` +- `src/lib/notification/deleteNotifications.ts` +- `src/lib/notification/getNotificationDestination.ts` +- `src/lib/notification/getNotifications.ts` +- `src/lib/notification/getNotificationState.ts` +- `src/lib/notification/index.ts` +- `src/lib/notification/markNotificationAsRead.ts` +- `src/lib/notification/sortNotifications.ts` +- `src/lib/notification/updateNotificationState.ts` +- `src/lib/fcmToken/upsertFcmToken.ts` +- `src/stores/useNotificationStore.ts` +- `src/hooks/useNotificationPermission.ts` +- `src/utils/requestNotificationPermission.ts` +- `src/utils/firebase/getFCMDeviceToken.ts` +- `src/utils/firebase/initFirebase.ts` +- `public/firebase-messaging-sw.js` +- `src/types/notification.ts` + +## 확인 필요 사항 +- 알림 목록 조회 실패 시 토스트 뒤에 재시도 버튼이 없으므로, 재시도 흐름을 별도 제공할지 기획 확인이 필요하다. +- 읽음 처리 요청 실패는 화면에서 무시하며 이미 읽은 모양과 개수로 유지한다. 서버 반영 실패를 사용자에게 알리거나 화면 상태를 되돌릴지 확인이 필요하다. +- 알림 설정 조회 및 저장 실패를 화면에서 처리하지 않는다. 오류 안내와 토글 상태 복구 정책을 확인한 뒤 실패 케이스를 추가해야 한다. +- `all_enabled`와 개별 설정값의 관계는 코드상 자동 계산되지 않는다. 개별 값을 변경할 때 전체 알림 토글도 함께 바뀌어야 하는지 확인이 필요하다. +- 비로그인 사용자가 알림 목록에 직접 접근하면 로딩 상태가 끝나지 않지만, 상위 라우트에서 접근을 막는지는 조사 범위만으로 확인할 수 없다. +- 아이오에스 사파리의 홈 화면 설치 안내와 알림 권한 거부 모달의 정확한 문구 및 닫기 동작은 모달 구현이 조사 범위 밖이므로, 자동화 시 실제 컴포넌트 확인이 필요하다. +- 서비스 워커의 알림 클릭 이동 처리는 주석 상태다. 푸시 알림 자체를 눌렀을 때 어느 화면으로 이동해야 하는지 기획 확인이 필요하다. +- `getFCMDeviceToken`은 토큰 저장 요청을 기다리지 않고, 토큰 발급 실패 재시도는 미구현 상태다. 이 흐름의 사용자 기대 동작을 확인한 뒤 케이스를 추가해야 한다. + +## 케이스 목록 + +### NOTI-LIST-001: 읽지 않은 알림이 읽은 알림보다 먼저 표시되고 각 그룹 안에서는 최신순으로 정렬된다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 알림 목록 정렬 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +알림 목록이 읽음 여부를 최우선으로, 같은 읽음 상태에서는 생성 시각과 아이디를 기준으로 안정적으로 정렬하는지 검증한다. + +## 시나리오 +사용자가 읽음 상태와 생성 시각이 서로 다른 알림이 있는 알림 목록을 연다. + +## Given +- 로그인 계정에 읽지 않은 알림 2개와 읽은 알림 2개가 있다. +- 각 상태 안에서 생성 시각이 서로 다르다. + +## When +- 세션을 주입한 뒤 `/notification`에 접속한다. + +## Then +- 읽지 않은 알림 2개가 읽은 알림 2개보다 앞에 표시된다. +- 읽지 않은 알림과 읽은 알림 각각은 최신 생성 시각 순서로 표시된다. +- 읽은 알림은 `bg-gray-200`, 읽지 않은 알림은 `bg-white` 상태로 구분된다. + +## 테스트 데이터 +- 동일 사용자 소유의 `notification` 4건 +- `is_read`와 `created_at` 조합이 정렬 결과를 식별할 수 있도록 서로 다른 제목을 사용한다. + +## 데이터 준비 방식 상세 +- Supabase Admin API 또는 테스트 Seed로 알림 4건을 삽입하고 인증 세션을 브라우저에 주입한다. + +## Cleanup 대상 +- 생성한 알림 4건을 삭제한다. + +## 예외/주의사항 +- 상대 시간 문구가 아니라 알림 제목의 화면 순서를 기준으로 검증한다. + +--- + +### NOTI-EMPTY-001: 알림이 없으면 빈 상태를 보여주고 모두 지우기 버튼을 비활성화한다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 알림 빈 상태 확인 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +알림이 없는 사용자가 빈 목록을 정상 상태로 인식할 수 있는지 검증한다. + +## 시나리오 +알림이 한 건도 없는 사용자가 알림 목록을 연다. + +## Given +- 로그인 계정 소유의 알림이 없다. + +## When +- 세션을 주입한 뒤 `/notification`에 접속한다. + +## Then +- `알림이 없어요.` 문구가 표시된다. +- `모두 지우기` 버튼이 비활성화된다. + +## 테스트 데이터 +- 알림이 없는 로그인 계정 + +## 데이터 준비 방식 상세 +- Seed 단계에서 해당 계정의 알림이 없음을 보장하고 인증 세션을 주입한다. + +## Cleanup 대상 +- 없다. + +## 예외/주의사항 +- 조회가 끝나기 전 스피너 상태를 빈 상태로 오인하지 않도록 문구가 나타날 때까지 기다린다. + +--- + +### NOTI-READ-001: 읽지 않은 알림을 누르면 즉시 읽음 상태가 되고 서버에도 반영된다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 알림 읽음 처리 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +사용자가 알림을 확인하면 화면의 읽지 않은 개수와 데이터베이스의 읽음 상태가 함께 갱신되는지 검증한다. + +## 시나리오 +사용자가 읽지 않은 채팅 알림을 누른다. + +## Given +- 로그인 계정에 유효한 `nbreadId`를 가진 읽지 않은 채팅 알림이 1건 있다. +- 읽지 않은 알림 개수 저장소 값이 목록 조회 결과와 일치한다. + +## When +- 알림 카드를 누른다. + +## Then +- 알림이 화면에서 읽은 배경 상태로 바뀐다. +- 읽지 않은 알림 개수가 1 감소한다. +- 해당 알림의 `is_read`가 `true`로 저장된다. +- `/nbread/{nbreadId}?tab=chat`으로 이동한다. + +## 테스트 데이터 +- 현재 사용자 소유 채팅 알림 1건과 접근 가능한 엔빵 아이디 + +## 데이터 준비 방식 상세 +- API Helper로 엔빵과 알림을 만들고 인증 세션을 주입한다. + +## Cleanup 대상 +- 생성한 알림과 엔빵 관련 테스트 데이터를 삭제한다. + +## 예외/주의사항 +- 화면 갱신은 서버 요청 완료를 기다리지 않으므로 데이터베이스 반영은 재시도 가능한 확인 방식으로 검증한다. + +--- + +### NOTI-NAVIGATE-001: 알림 유형과 데이터에 맞는 서비스 화면으로 이동한다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 알림 목적지 이동 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +각 알림 유형의 데이터 키가 올바른 내부 경로로 변환되는지 검증한다. + +## 시나리오 +사용자가 목적지 정보가 있는 알림을 유형별로 누른다. + +## Given +- `inviteToken`이 있는 초대 알림, `nbread_id`가 있는 결제 알림, 친구 응답 알림이 각각 있다. + +## When +- 각 알림을 독립된 테스트 실행에서 누른다. + +## Then +- 초대 알림은 `/invite/{inviteToken}`으로 이동한다. +- 결제 알림은 `/nbread/{nbreadId}`로 이동한다. +- 친구 응답 알림은 `/friendList`로 이동한다. + +## 테스트 데이터 +- 현재 사용자 소유의 `invite`, `payment`, `friend_response` 알림 +- 경로에서 식별 가능한 토큰과 엔빵 아이디 + +## 데이터 준비 방식 상세 +- API Helper로 각 실행에 필요한 알림 1건을 준비하고 세션을 주입한다. + +## Cleanup 대상 +- 생성한 알림과 연관 테스트 데이터를 삭제한다. + +## 예외/주의사항 +- 하나의 Playwright `test()`에서는 한 유형만 검증하도록 데이터 주도 테스트를 각각 독립 생성한다. +- 카멜 표기와 밑줄 표기 키를 모두 지원하지만, 이 케이스에서는 실제 저장 형태 중 하나를 사용한다. + +--- + +### NOTI-NAVIGATE-002: 목적지 정보가 없는 알림을 누르면 이동하지 않고 오류를 안내한다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 알림 목적지 누락 처리 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +필수 목적지 데이터가 누락된 알림이 잘못된 화면으로 이동시키지 않는지 검증한다. + +## 시나리오 +사용자가 초대 토큰이 없는 초대 알림을 누른다. + +## Given +- 로그인 계정에 `data`가 `null`인 읽지 않은 초대 알림이 있다. + +## When +- 해당 알림 카드를 누른다. + +## Then +- 현재 알림 화면에 머문다. +- `초대 정보를 찾을 수 없어요.` 토스트가 표시된다. +- 해당 알림은 읽음 상태로 바뀐다. + +## 테스트 데이터 +- 현재 사용자 소유의 목적지 데이터 없는 `invite` 알림 1건 + +## 데이터 준비 방식 상세 +- Seed로 `data: null` 알림을 삽입하고 인증 세션을 주입한다. + +## Cleanup 대상 +- 생성한 알림을 삭제한다. + +## 예외/주의사항 +- 목적지 유효성 검사보다 읽음 처리가 먼저 실행되는 현재 코드 순서를 함께 검증한다. + +--- + +### NOTI-FRIEND-REQUEST-001: 친구 요청 알림을 누르면 발신자 정보가 담긴 수락 모달을 연다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 친구 요청 알림 확인 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +친구 요청 알림이 별도 페이지 이동 대신 발신자 정보를 이용한 수락 모달을 여는지 검증한다. + +## 시나리오 +수신 사용자가 친구 요청 알림을 누른다. + +## Given +- 발신 계정과 수신 계정이 있다. +- 수신 계정에 `sender_id`, `sender_name`이 담긴 읽지 않은 `friend_request` 알림이 있다. + +## When +- 수신 계정 세션으로 알림 카드를 누른다. + +## Then +- 페이지 이동 없이 친구 수락 모달이 열린다. +- 모달에 전달된 발신자 이름이 표시된다. +- 알림이 읽음 상태로 바뀐다. + +## 테스트 데이터 +- 발신자와 수신자 계정, 친구 요청 알림 1건 + +## 데이터 준비 방식 상세 +- API Helper로 두 계정과 알림 데이터를 준비하고 수신자 세션을 주입한다. + +## Cleanup 대상 +- 알림, 친구 관계 또는 요청 데이터, 테스트 계정을 삭제한다. + +## 예외/주의사항 +- 모달에서 수락하는 후속 흐름은 친구 도메인 범위이므로 여기서는 모달 열림까지만 검증한다. + +--- + +### NOTI-DELETE-001: 알림 하나를 지우면 해당 알림만 사라지고 읽지 않은 개수가 다시 계산된다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 알림 단건 삭제 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +단건 삭제가 대상 알림에만 적용되고 화면의 읽지 않은 개수도 일관되게 갱신되는지 검증한다. + +## 시나리오 +사용자가 읽지 않은 알림의 지우기 버튼을 누른다. + +## Given +- 로그인 계정에 서로 다른 제목의 읽지 않은 알림과 읽은 알림이 각각 1건 있다. + +## When +- 읽지 않은 알림의 `{제목} 알림 지우기` 버튼을 누른다. + +## Then +- 대상 알림만 목록에서 사라진다. +- 다른 알림은 유지된다. +- 읽지 않은 알림 개수가 1 감소한다. +- 대상 행이 데이터베이스에서 삭제된다. +- 알림 카드의 목적지로 이동하지 않는다. + +## 테스트 데이터 +- 현재 사용자 소유 알림 2건 + +## 데이터 준비 방식 상세 +- API Helper로 알림을 만들고 인증 세션을 주입한다. + +## Cleanup 대상 +- 남은 알림을 삭제한다. + +## 예외/주의사항 +- 삭제 버튼은 카드 클릭 전파를 막으므로 경로가 바뀌지 않는지도 검증한다. + +--- + +### NOTI-DELETE-002: 알림 하나를 지우지 못하면 목록을 유지하고 실패를 안내한다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 알림 단건 삭제 실패 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +삭제 요청 실패 시 성공한 것처럼 화면에서 알림을 제거하지 않는지 검증한다. + +## 시나리오 +사용자가 알림을 지우지만 Supabase 삭제 요청이 실패한다. + +## Given +- 로그인 계정에 알림 1건이 표시되어 있다. +- 해당 단건 삭제 요청은 오류를 반환하도록 가로챈다. + +## When +- 알림 지우기 버튼을 누른다. + +## Then +- `알림 삭제에 실패했어요. 다시 시도해주세요.` 토스트가 표시된다. +- 대상 알림이 목록에 그대로 남는다. +- 요청 종료 뒤 지우기 버튼이 다시 활성화된다. + +## 테스트 데이터 +- 현재 사용자 소유 알림 1건 + +## 데이터 준비 방식 상세 +- 알림은 API Helper로 만들고, Playwright 네트워크 Mock으로 삭제 응답만 실패시킨다. + +## Cleanup 대상 +- 생성한 알림을 삭제한다. + +## 예외/주의사항 +- Supabase 요청 주소와 응답 형식은 자동화 구현 시 클라이언트 설정을 확인해 맞춘다. + +--- + +### NOTI-DELETE-ALL-001: 모두 지우기를 누르면 현재 사용자의 모든 알림을 삭제한다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 알림 전체 삭제 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +전체 삭제가 현재 사용자 범위에만 적용되고 화면과 알림 개수를 빈 상태로 갱신하는지 검증한다. + +## 시나리오 +알림이 여러 개 있는 사용자가 모두 지우기를 누른다. + +## Given +- 로그인 사용자에게 알림 3건이 있다. +- 다른 사용자에게도 알림 1건이 있다. + +## When +- 로그인 사용자 화면에서 `모두 지우기`를 누른다. + +## Then +- 로그인 사용자의 목록이 `알림이 없어요.` 상태로 바뀐다. +- 읽지 않은 알림 개수가 0이 된다. +- 로그인 사용자의 알림만 데이터베이스에서 삭제된다. +- 다른 사용자의 알림은 유지된다. +- `모두 지우기` 버튼이 비활성화된다. + +## 테스트 데이터 +- 두 사용자 계정과 사용자별 알림 총 4건 + +## 데이터 준비 방식 상세 +- API Helper로 계정과 알림을 만들고 첫 번째 사용자 세션을 주입한다. + +## Cleanup 대상 +- 남은 다른 사용자 알림과 테스트 계정을 삭제한다. + +## 예외/주의사항 +- 다른 사용자 데이터 보존은 화면이 아니라 API Helper 또는 데이터베이스 조회로 확인한다. + +--- + +### NOTI-SETTINGS-DEFAULT-001: 알림 설정이 없는 사용자가 처음 열면 모든 설정을 켠 기본값을 만든다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 알림 설정 최초 생성 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +설정 행이 없는 신규 사용자에게 코드에 정의된 기본 알림 설정이 생성되는지 검증한다. + +## 시나리오 +알림 설정을 한 번도 저장하지 않은 사용자가 설정 화면을 연다. + +## Given +- 로그인 계정의 `user_notification_settings` 행이 없다. + +## When +- 세션을 주입한 뒤 `/mypage/notification-setting`에 접속한다. + +## Then +- 전체, 채팅, 초대, 친구, 정산 알림 토글이 모두 켜져 표시된다. +- 사용자 아이디 기준 설정 행이 1건 생성된다. +- 다섯 설정 열의 값이 모두 `true`다. + +## 테스트 데이터 +- 알림 설정 행이 없는 로그인 계정 + +## 데이터 준비 방식 상세 +- Seed로 계정을 만들고 설정 행이 없음을 보장한 뒤 세션을 주입한다. + +## Cleanup 대상 +- 자동 생성된 설정 행과 테스트 계정을 삭제한다. + +## 예외/주의사항 +- 페이지 진입 과정에서 권한 요청은 자동 실행되지 않는다. 이 화면은 훅에 `autoRequest: false`를 전달한다. + +--- + +### NOTI-SETTINGS-ALL-001: 전체 알림을 끄면 모든 개별 알림도 함께 꺼진다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 전체 알림 설정 변경 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +전체 알림 끄기가 화면과 저장 데이터의 모든 알림 항목에 동일하게 적용되는지 검증한다. + +## 시나리오 +모든 알림이 켜진 사용자가 전체 알림을 끈다. + +## Given +- 전체와 네 개별 알림 설정이 모두 `true`다. + +## When +- `전체 알림 설정` 토글을 누른다. + +## Then +- 전체, 채팅, 초대, 친구, 정산 알림 토글이 모두 꺼진다. +- 설정 행의 다섯 설정 열이 모두 `false`로 저장된다. + +## 테스트 데이터 +- 모든 알림 설정이 켜진 사용자 설정 행 + +## 데이터 준비 방식 상세 +- Seed로 사용자와 설정 행을 만들고 세션을 주입한다. + +## Cleanup 대상 +- 설정 행과 테스트 계정을 삭제한다. + +## 예외/주의사항 +- 끄기 동작에는 브라우저 알림 권한 요청이 발생하지 않아야 한다. + +--- + +### NOTI-SETTINGS-ITEM-001: 개별 알림을 끄면 선택한 항목만 변경된다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 개별 알림 설정 변경 | +| 케이스 유형 | 회귀 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +개별 토글 변경이 다른 알림 설정을 덮어쓰지 않는지 검증한다. + +## 시나리오 +모든 개별 알림이 켜진 사용자가 채팅 알림만 끈다. + +## Given +- 전체와 네 개별 알림 설정이 모두 `true`다. + +## When +- `채팅 알림 설정` 토글을 누른다. + +## Then +- 채팅 알림 토글만 꺼진다. +- 초대, 친구, 정산 알림 토글과 전체 알림 토글은 기존 상태를 유지한다. +- 데이터베이스에서는 `chat_enabled`만 `false`로 변경된다. + +## 테스트 데이터 +- 모든 알림 설정이 켜진 사용자 설정 행 + +## 데이터 준비 방식 상세 +- Seed로 사용자와 설정 행을 만들고 세션을 주입한다. + +## Cleanup 대상 +- 설정 행과 테스트 계정을 삭제한다. + +## 예외/주의사항 +- 전체 알림 값의 자동 재계산은 구현되어 있지 않으므로 현재 동작을 회귀 기준으로 기록한다. + +--- + +### NOTI-PERMISSION-001: 알림 권한을 거부하면 설정을 켜지 않고 권한 거부 안내를 연다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 알림 권한 거부 처리 | +| 케이스 유형 | 권한 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +운영체제 알림 권한이 없는 상태에서 서비스 설정만 잘못 켜지는 것을 방지하는지 검증한다. + +## 시나리오 +알림이 꺼진 사용자가 전체 알림을 켜려 하지만 브라우저 권한 요청을 거부한다. + +## Given +- 사용자 설정의 다섯 알림 값이 모두 `false`다. +- 브라우저의 알림 권한 상태는 `default`이고 권한 요청 결과는 `denied`다. + +## When +- `전체 알림 설정` 토글을 누르고 권한 요청을 거부한다. + +## Then +- 권한 거부 안내 모달이 열린다. +- 전체 및 개별 알림 토글은 모두 꺼진 상태를 유지한다. +- 설정 데이터는 변경되지 않는다. + +## 테스트 데이터 +- 모든 알림 설정이 꺼진 사용자 설정 행 + +## 데이터 준비 방식 상세 +- 설정 데이터와 세션을 준비하고, 브라우저 컨텍스트 또는 초기화 스크립트로 Notification API 결과를 제어한다. + +## Cleanup 대상 +- 설정 행과 테스트 계정을 삭제하고 브라우저 권한 상태를 초기화한다. + +## 예외/주의사항 +- 실제 운영체제 권한 대화상자를 자동화하지 않고 Notification API를 Mock한다. + +--- + +### NOTI-IOS-GUIDE-001: 홈 화면에 설치하지 않은 아이오에스 사파리에서는 설치 안내를 보여준다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 아이오에스 알림 사용 안내 | +| 케이스 유형 | 권한 | +| 우선순위 | P2 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +웹 푸시를 바로 요청할 수 없는 아이오에스 사파리 환경에서 올바른 설치 안내로 분기하는지 검증한다. + +## 시나리오 +홈 화면에 설치하지 않은 아이오에스 사파리 사용자가 꺼진 개별 알림을 켜려 한다. + +## Given +- 사용자 에이전트가 아이오에스 사파리로 인식된다. +- `display-mode: standalone`은 일치하지 않는다. +- 채팅 알림 설정이 꺼져 있다. + +## When +- `채팅 알림 설정` 토글을 누른다. + +## Then +- 아이오에스 홈 화면 설치 안내 모달이 열린다. +- 일반 권한 거부 모달은 열리지 않는다. +- 채팅 알림 토글과 저장 데이터는 꺼진 상태를 유지한다. + +## 테스트 데이터 +- 채팅 알림이 꺼진 사용자 설정 행 + +## 데이터 준비 방식 상세 +- 설정 데이터와 세션을 준비하고, Playwright 프로젝트 설정과 초기화 스크립트로 사용자 에이전트 및 `matchMedia` 결과를 제어한다. + +## Cleanup 대상 +- 설정 행과 테스트 계정을 삭제한다. + +## 예외/주의사항 +- 아이오에스의 크롬, 파이어폭스, 엣지, 오페라는 코드상 이 안내 대상에서 제외된다. + +--- + +### NOTI-LOAD-001: 알림 목록 조회가 실패하면 오류를 안내하고 빈 목록 상태를 유지한다 +| 속성 | 값 | +|---|---| +| 도메인 | 알림 | +| 시나리오 | 알림 목록 조회 실패 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +알림 조회 오류가 무한 로딩이나 화면 중단으로 이어지지 않고 사용자에게 안내되는지 검증한다. + +## 시나리오 +사용자가 알림 목록을 열지만 Supabase 조회 요청이 실패한다. + +## Given +- 유효한 로그인 세션이 있다. +- 알림 목록 조회 요청은 오류를 반환하도록 가로챈다. + +## When +- `/notification`에 접속한다. + +## Then +- 로딩 스피너가 종료된다. +- `알림을 불러오지 못했어요. 다시 시도해주세요.` 토스트가 표시된다. +- 알림 카드는 표시되지 않는다. + +## 테스트 데이터 +- 유효한 로그인 계정 + +## 데이터 준비 방식 상세 +- 인증 세션을 주입하고 Playwright 네트워크 Mock으로 알림 조회 응답을 실패시킨다. + +## Cleanup 대상 +- 없다. + +## 예외/주의사항 +- 현재 구현은 실패 후 빈 상태 문구도 함께 표시할 수 있으므로, 오류와 실제 빈 상태를 구분하는 기획은 확인 필요 사항으로 남긴다. diff --git a/llm-wiki/output/2026-08-14-e2e-tc-draft-settlement.md b/llm-wiki/output/2026-08-14-e2e-tc-draft-settlement.md new file mode 100644 index 0000000..18650ff --- /dev/null +++ b/llm-wiki/output/2026-08-14-e2e-tc-draft-settlement.md @@ -0,0 +1,563 @@ +# 정산 도메인 E2E 테스트 케이스 초안 + +## 조사한 코드 +- `src/lib/nbreadRecord/getNbreadRecords.ts` +- `src/lib/nbreadRecord/index.ts` +- `src/lib/nbreadRecord/updateNbreadRecord.ts` +- `src/lib/participant/deleteParticipant.ts` +- `src/lib/participant/getParticipants.ts` +- `src/lib/participant/index.ts` +- `src/lib/participant/insertParticipant.ts` +- `src/stores/useNbreadPaymentState.tsx` +- `src/utils/testSendPaymentNotification.ts` +- `src/components/nbread/nbreadCard.tsx` +- `src/components/nbread/NbreadDetail.tsx` +- `src/components/nbread/nbreadEditCard.tsx` +- `src/components/nbread/nbreadParticipantCard.tsx` +- `src/components/nbread/nbreadParticipantsList.tsx` +- `supabase/functions/payment-notification/index.ts` +- `supabase/functions/payment-notification/deno.json` +- `supabase/cron/auto-generate-nbread-records.sql` +- `supabase/migrations/20260517101517_auto_generate_nbread_records.sql` +- `supabase/migrations/20260518043355_restrict_init_payment_dates_trigger.sql` +- `supabase/migrations/20260518051937_fix_nbread_auto_generation_cycle.sql` +- `supabase/migrations/20260518053956_rename_nbread_payment_dates_to_period_dates.sql` +- `supabase/migrations/20260518060953_fix_initial_nbread_records_start_date.sql` + +## 확인 필요 사항 +- `NbreadDetail`은 정산 기록 조회나 참여자 조회가 실패했을 때 화면 오류 상태로 전환하지 않으므로, 로딩 표시를 계속 유지하는 것이 의도된 동작인지 확인이 필요하다. +- `NbreadParticipantCard`의 체크 처리 실패 시 오류 토스트를 표시한 뒤 오류를 다시 던지므로, 브라우저의 처리되지 않은 프로미스 오류까지 허용할지 확인이 필요하다. +- 납부 완료 알림 함수는 요청 본문을 메서드 검사보다 먼저 파싱하므로, 본문 없는 `OPTIONS` 및 `GET` 요청에서 의도한 응답을 보장하는지 확인이 필요하다. +- 납부 완료 알림 저장 함수인 `insertNotificationResult`를 기다리지 않고 호출하므로, 함수가 200을 반환한 시점에 알림 행 저장까지 보장해야 하는지 확인이 필요하다. +- `testSendPaymentNotification.ts`에는 고정 식별자와 고정 토큰이 들어 있고 조회한 세션 토큰을 사용하지 않으므로, 실제 테스트 보조 도구로 유지할 코드인지 확인이 필요하다. +- 자동 정산 기록 생성 함수와 크론 설정은 데이터베이스 및 엣지 함수 수준의 통합 검증 대상이다. 이를 Playwright 한 흐름에 포함할지 별도 통합 테스트로 관리할지 확인이 필요하다. +- (검토 반영) Case ID는 시나리오 단위로 번호를 다시 매겼다(도메인-시나리오-001 형식). 각 시나리오가 서로 달라 대부분 001로 시작하며, 같은 시나리오가 여러 케이스로 갈리는 경우는 없었다. +- (검토 반영) 계정 조건의 "관리자 또는 그룹장" 표기를 Notion select 옵션과 동일한 "관리자/그룹장"으로 통일했다. +- (검토 반영) TOGGLE-UNDO, THROTTLE, PERIOD-CURRENT 케이스는 버그 재현이 아니라 정상 동작 검증이라 케이스 유형을 "회귀"에서 "성공"으로 바꿨다. + +## 케이스 목록 + +### SETTLE-TOGGLE-BY-ADMIN-001: 그룹장이 참여자의 납부 상태를 완료로 변경한다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 납부 완료 처리 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 관리자/그룹장 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +그룹장이 현재 정산 기간에 속한 다른 참여자의 납부 상태를 완료로 바꿀 수 있는지 검증한다. + +## 시나리오 +그룹장 세션으로 그룹 상세 화면을 열고 미납 참여자의 체크박스를 선택한다. + +## Given +- 그룹장과 일반 참여자가 포함된 그룹이 있다. +- 그룹의 `start_date`와 같은 `payment_date`를 가진 두 참여자의 `nbread_records`가 있고 일반 참여자의 `is_paid`는 `false`다. + +## When +- 그룹장 세션을 주입하고 그룹 상세 화면에 접속한다. +- 일반 참여자의 납부 체크박스를 선택한다. + +## Then +- 완료 상태가 갱신되었다는 성공 토스트가 보인다. +- 해당 체크박스가 선택 상태로 바뀐다. +- 해당 참여자의 현재 기간 `nbread_records.is_paid`가 `true`다. + +## 테스트 데이터 +- 그룹장 1명, 일반 참여자 1명, 현재 기간 미납 기록 2건 + +## 데이터 준비 방식 상세 +Seed로 그룹, 참여자, 현재 기간 정산 기록을 만들고 Supabase Admin API로 만든 그룹장 세션을 브라우저에 주입한다. + +## Cleanup 대상 +생성한 정산 기록, 참여자, 그룹, 사용자 데이터를 삭제한다. + +## 예외/주의사항 +UI 상태만 확인하지 말고 데이터베이스의 대상 사용자와 `payment_date`가 정확히 갱신됐는지 확인한다. + +--- + +### SETTLE-TOGGLE-SELF-001: 일반 참여자가 자신의 납부 상태를 완료로 변경한다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 본인 납부 완료 처리 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +그룹장이 아닌 참여자도 자신의 현재 기간 납부 상태는 변경할 수 있는지 검증한다. + +## 시나리오 +일반 참여자가 그룹 상세 화면에서 자신의 미납 체크박스를 선택한다. + +## Given +- 그룹장과 로그인할 일반 참여자가 포함된 그룹이 있다. +- 로그인할 참여자의 현재 기간 정산 기록은 미납 상태다. + +## When +- 일반 참여자 세션을 주입하고 그룹 상세 화면에 접속한다. +- 자신의 납부 체크박스를 선택한다. + +## Then +- 자신의 체크박스가 활성화되어 있다. +- 성공 토스트가 보이고 체크박스가 선택 상태로 바뀐다. +- 자신의 현재 기간 정산 기록만 `is_paid = true`로 갱신된다. + +## 테스트 데이터 +- 그룹장 1명, 로그인할 일반 참여자 1명, 현재 기간 미납 기록 + +## 데이터 준비 방식 상세 +Seed로 그룹과 정산 기록을 구성하고 일반 참여자의 세션을 주입한다. + +## Cleanup 대상 +생성한 정산 기록, 참여자, 그룹, 사용자 데이터를 삭제한다. + +## 예외/주의사항 +다른 참여자의 기록이 함께 바뀌지 않았는지 확인한다. + +--- + +### SETTLE-TOGGLE-PERMISSION-001: 일반 참여자는 다른 참여자의 납부 상태를 변경할 수 없다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 다른 참여자 납부 상태 접근 제한 | +| 케이스 유형 | 권한 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 권한 없음 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +그룹장이 아닌 참여자가 다른 참여자의 납부 상태를 바꾸지 못하도록 화면에서 제한하는지 검증한다. + +## 시나리오 +일반 참여자가 여러 참여자가 있는 그룹의 정산 목록을 확인한다. + +## Given +- 그룹장, 로그인할 일반 참여자, 다른 일반 참여자가 포함된 그룹이 있다. +- 세 사용자의 현재 기간 정산 기록이 있다. + +## When +- 일반 참여자 세션을 주입하고 그룹 상세 화면에 접속한다. + +## Then +- 본인의 체크박스만 활성화되어 있다. +- 그룹장과 다른 일반 참여자의 체크박스는 비활성화되어 조작할 수 없다. +- 다른 사용자의 `nbread_records`는 변경되지 않는다. + +## 테스트 데이터 +- 그룹장 1명, 일반 참여자 2명, 현재 기간 정산 기록 3건 + +## 데이터 준비 방식 상세 +Seed로 세 사용자의 참여 관계와 정산 기록을 만들고 권한 없는 일반 참여자의 세션을 주입한다. + +## Cleanup 대상 +생성한 정산 기록, 참여자, 그룹, 사용자 데이터를 삭제한다. + +## 예외/주의사항 +이 케이스는 컴포넌트의 `disabled` 조건을 검증하며 데이터베이스 정책 자체의 권한 검증은 별도 범위다. + +--- + +### SETTLE-TOGGLE-UNDO-001: 완료된 납부 상태를 다시 미납으로 변경한다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 납부 완료 취소 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 관리자/그룹장 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +체크된 납부 상태를 다시 선택하면 반대 상태로 정상 갱신되는지 검증한다. + +## 시나리오 +그룹장이 납부 완료 상태인 참여자의 체크박스를 해제한다. + +## Given +- 대상 참여자의 현재 기간 정산 기록이 `is_paid = true`다. + +## When +- 그룹장 세션으로 그룹 상세 화면을 열고 대상 참여자의 선택된 체크박스를 해제한다. + +## Then +- 성공 토스트가 보인다. +- 체크박스가 선택되지 않은 상태로 바뀐다. +- 대상 기록의 `is_paid`가 `false`로 갱신된다. + +## 테스트 데이터 +- 그룹장과 일반 참여자, 납부 완료 상태의 현재 기간 정산 기록 + +## 데이터 준비 방식 상세 +Seed로 완료 상태 기록을 만들고 그룹장 세션을 주입한다. + +## Cleanup 대상 +생성한 정산 기록, 참여자, 그룹, 사용자 데이터를 삭제한다. + +## 예외/주의사항 +완료에서 미납으로 바뀌는 웹훅은 알림 함수에서 204로 종료되는 분기와 연결된다. + +--- + +### SETTLE-UPDATE-FAIL-001: 납부 상태 저장에 실패하면 화면 상태를 유지하고 오류를 알린다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 납부 상태 갱신 실패 처리 | +| 케이스 유형 | 실패 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 관리자/그룹장 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +정산 기록 갱신 요청이 실패했을 때 성공한 것처럼 화면 상태가 바뀌지 않는지 검증한다. + +## 시나리오 +그룹장이 미납 체크박스를 선택하지만 Supabase 갱신 요청이 실패한다. + +## Given +- 미납 상태의 참여자가 표시된 그룹 상세 화면이 열려 있다. +- `nbread_records` 갱신 요청이 오류를 반환하도록 가로챈다. + +## When +- 대상 참여자의 체크박스를 선택한다. + +## Then +- 납부 상태 갱신 실패 오류 토스트가 보인다. +- 체크박스는 기존 미선택 상태를 유지한다. +- 성공 토스트는 보이지 않는다. + +## 테스트 데이터 +- 화면 조회에 필요한 그룹장, 참여자, 미납 정산 기록 응답 + +## 데이터 준비 방식 상세 +조회 데이터는 고정하고 정산 기록 갱신 요청만 실패 응답으로 Mock한다. + +## Cleanup 대상 +Mock 해제 외 데이터 정리는 필요하지 않다. + +## 예외/주의사항 +컴포넌트가 오류를 다시 던지므로 Playwright에서 처리되지 않은 오류를 별도로 수집해 예상 오류인지 확인한다. + +--- + +### SETTLE-THROTTLE-001: 납부 체크박스를 연속으로 선택해도 갱신 요청은 한 번만 전송된다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 납부 상태 중복 갱신 방지 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 관리자/그룹장 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +체크 처리 뒤 3초 동안 중복 실행을 막는 방어 로직이 이중 갱신을 방지하는지 검증한다. + +## 시나리오 +그룹장이 같은 미납 체크박스를 짧은 간격으로 두 번 선택한다. + +## Given +- 미납 참여자의 체크박스가 활성화되어 있다. +- 정산 기록 갱신 요청 횟수를 셀 수 있도록 요청을 가로챈다. + +## When +- 같은 체크박스에 3초 이내로 두 번의 변경 동작을 발생시킨다. + +## Then +- `nbread_records` 갱신 요청은 한 번만 발생한다. +- 체크 상태는 한 번만 반전되어 완료 상태다. + +## 테스트 데이터 +- 그룹장, 일반 참여자, 현재 기간 미납 기록 + +## 데이터 준비 방식 상세 +화면 데이터를 제공하고 갱신 요청을 성공 응답하는 Mock에서 호출 횟수를 기록한다. + +## Cleanup 대상 +Mock 해제 외 데이터 정리는 필요하지 않다. + +## 예외/주의사항 +브라우저 클릭 자체가 비활성 요소에 의해 차단되는지보다 갱신 요청 횟수를 최종 기준으로 삼는다. + +--- + +### SETTLE-PERIOD-CURRENT-001: 현재 정산 기간의 납부 기록만 참여자 목록에 반영된다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 현재 기간 정산 기록 조회 | +| 케이스 유형 | 성공 | +| 우선순위 | P0 | +| 데이터 준비 방식 | Seed | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +그룹의 `start_date`와 일치하는 정산 기록만 조회해 현재 화면의 체크 상태를 구성하는지 검증한다. + +## 시나리오 +같은 참여자에게 이전 기간 완료 기록과 현재 기간 미납 기록이 있는 그룹 상세 화면을 연다. + +## Given +- 한 참여자에게 서로 다른 `payment_date`의 정산 기록이 두 건 있다. +- 이전 기간 기록은 완료, 그룹의 `start_date`와 같은 현재 기간 기록은 미납이다. + +## When +- 참여자 세션을 주입하고 그룹 상세 화면에 접속한다. + +## Then +- 해당 참여자의 체크박스는 현재 기간 기록을 따라 미선택 상태로 보인다. +- 이전 기간의 완료 상태가 현재 화면에 섞이지 않는다. + +## 테스트 데이터 +- 이전 기간 완료 기록 1건, 현재 기간 미납 기록 1건, 그룹과 참여자 + +## 데이터 준비 방식 상세 +Seed로 동일한 그룹과 사용자에 대해 날짜가 다른 두 정산 기록을 만든다. + +## Cleanup 대상 +두 정산 기록과 참여자, 그룹, 사용자 데이터를 삭제한다. + +## 예외/주의사항 +조회 함수는 전달받은 날짜를 국제 표준시 기준 날짜 문자열로 변환하므로 테스트 데이터의 날짜 경계를 고정한다. + +--- + +### SETTLE-PERIOD-INITIAL-001: 새 참여자가 추가되면 그룹 시작일 기준의 미납 기록이 한 건 생성된다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 참여자 최초 정산 기록 생성 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +참여자 추가 트리거가 그룹의 시작일을 사용해 최초 정산 기록을 생성하는지 검증한다. + +## 시나리오 +기존 그룹에 새 사용자를 참여자로 추가한 뒤 그룹 상세 화면을 확인한다. + +## Given +- `start_date`가 설정된 그룹과 아직 참여하지 않은 사용자가 있다. + +## When +- API Helper로 새 사용자를 `participant`에 추가한다. +- 새 참여자 세션으로 그룹 상세 화면을 연다. + +## Then +- 새 참여자에 대해 `payment_date = nbread.start_date`, `is_paid = false`인 정산 기록이 한 건 존재한다. +- 새 참여자의 체크박스가 미선택 상태로 표시된다. + +## 테스트 데이터 +- 시작일이 있는 그룹, 그룹장, 새 참여자 + +## 데이터 준비 방식 상세 +그룹과 계정은 Seed로 만들고 참여자 삽입은 API Helper로 실행해 데이터베이스 트리거를 통과시킨다. + +## Cleanup 대상 +자동 생성된 정산 기록, 참여자, 그룹, 사용자 데이터를 삭제한다. + +## 예외/주의사항 +마이그레이션은 같은 그룹, 날짜, 사용자 조합의 충돌을 무시하므로 정확히 한 건인지 확인한다. + +--- + +### SETTLE-NOTIFICATION-SEND-001: 납부 완료 알림은 납부자를 제외한 알림 허용 참여자에게 전송된다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 납부 완료 알림 전송 | +| 케이스 유형 | 성공 | +| 우선순위 | P1 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 필요 | +| 관련 Issue | | + +## 목적 +미납에서 완료로 바뀐 웹훅이 납부자 자신을 제외하고 납부 알림을 허용한 참여자에게만 알림을 보내는지 검증한다. + +## 시나리오 +참여자의 납부 상태를 완료로 변경하고 결제 알림 함수의 결과를 확인한다. + +## Given +- 납부자, 알림 허용 참여자, 알림 비허용 참여자가 같은 그룹에 있다. +- 알림 허용 참여자와 납부자에게 FCM 토큰이 있다. +- FCM 전송은 성공 결과를 반환하도록 Mock한다. + +## When +- `old_record.is_paid = false`, `record.is_paid = true`인 POST 웹훅을 결제 알림 함수에 전달한다. + +## Then +- 함수는 200을 반환한다. +- FCM 전송 대상에는 알림 허용 참여자의 토큰만 포함된다. +- 납부자와 알림 비허용 참여자는 전송 대상에서 제외된다. +- 성공한 알림 허용 참여자에게 `type = payment`이고 그룹 식별자를 담은 알림 결과가 저장된다. + +## 테스트 데이터 +- 그룹 1개, 참여자 3명, 알림 설정, FCM 토큰, 납부 전후 웹훅 본문 + +## 데이터 준비 방식 상세 +Supabase 조회 결과와 FCM 전송 결과를 Mock하고 함수 호출 및 알림 저장 인자를 수집한다. + +## Cleanup 대상 +통합 환경에 저장된 알림 결과가 있다면 삭제한다. + +## 예외/주의사항 +한 사용자에게 여러 성공 토큰이 있어도 알림 결과는 사용자별 한 번만 저장하는 코드 분기를 함께 확인한다. + +--- + +### SETTLE-NOTIFICATION-SKIP-001: 완료 상태가 새로 생기지 않은 웹훅은 알림을 보내지 않는다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 납부 알림 불필요 웹훅 무시 | +| 케이스 유형 | 예외 | +| 우선순위 | P1 | +| 데이터 준비 방식 | API Helper | +| 계정 조건 | 로그인 1계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +이미 완료였던 기록의 갱신 또는 미납으로의 변경에서 중복 알림이 발생하지 않는지 검증한다. + +## 시나리오 +완료 상태가 새로 만들어지지 않은 정산 기록 웹훅을 결제 알림 함수에 전달한다. + +## Given +- `old_record.is_paid = true`인 웹훅 본문을 준비한다. + +## When +- 결제 알림 함수에 본문을 POST한다. + +## Then +- 함수는 본문 없이 204를 반환한다. +- 그룹, 사용자, 참여자, FCM 토큰 조회 및 알림 전송이 발생하지 않는다. +- 알림 결과가 저장되지 않는다. + +## 테스트 데이터 +- 완료 상태였던 정산 기록의 갱신 웹훅 본문 + +## 데이터 준비 방식 상세 +API Helper로 함수에 웹훅 본문을 직접 전송하고 외부 호출 기록을 확인한다. + +## Cleanup 대상 +데이터를 생성하지 않는다. + +## 예외/주의사항 +`record.is_paid = false`인 경우도 같은 204 분기지만 하나의 Playwright `test()`와 한 행의 대응을 유지하려면 별도 자동화가 필요할 때 케이스를 추가한다. + +--- + +### SETTLE-NOTIFICATION-PREFERENCE-001: 납부 알림을 받을 참여자가 없으면 전송 없이 종료한다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 납부 알림 수신 대상 없음 처리 | +| 케이스 유형 | 예외 | +| 우선순위 | P2 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +납부자를 제외한 참여자 중 납부 알림을 허용한 사용자가 없을 때 불필요한 FCM 처리를 하지 않는지 검증한다. + +## 시나리오 +모든 다른 참여자가 납부 알림을 끈 그룹의 완료 웹훅을 전달한다. + +## Given +- 납부자 외 참여자는 있지만 알림 설정 필터 결과가 빈 배열이다. +- 미납에서 완료로 바뀐 웹훅 본문이 있다. + +## When +- 결제 알림 함수에 웹훅을 POST한다. + +## Then +- 함수는 204를 반환한다. +- FCM 토큰 조회와 FCM 전송이 발생하지 않는다. +- 알림 결과가 저장되지 않는다. + +## 테스트 데이터 +- 그룹과 사용자 조회 응답, 참여자 목록, 빈 알림 허용 사용자 목록 + +## 데이터 준비 방식 상세 +함수의 데이터 조회와 알림 설정 필터 결과를 Mock한다. + +## Cleanup 대상 +Mock 해제 외 데이터 정리는 필요하지 않다. + +## 예외/주의사항 +납부자 제외 로직 뒤에 알림 설정 필터가 적용되는 순서를 확인한다. + +--- + +### SETTLE-NOTIFICATION-TOKEN-001: 알림 대상의 FCM 토큰을 찾지 못하면 오류를 반환한다 +| 속성 | 값 | +|---|---| +| 도메인 | 정산 | +| 시나리오 | 납부 알림 토큰 조회 실패 처리 | +| 케이스 유형 | 실패 | +| 우선순위 | P2 | +| 데이터 준비 방식 | Mock | +| 계정 조건 | 로그인 2계정 | +| Cleanup | 불필요 | +| 관련 Issue | | + +## 목적 +알림 허용 대상은 있지만 FCM 토큰이 없을 때 함수가 성공으로 오인하지 않는지 검증한다. + +## 시나리오 +알림 허용 참여자의 FCM 토큰 조회 결과가 비어 있는 완료 웹훅을 처리한다. + +## Given +- 납부자 외에 알림을 허용한 참여자가 있다. +- FCM 토큰 조회는 빈 배열을 반환한다. + +## When +- 미납에서 완료로 바뀐 웹훅을 결제 알림 함수에 POST한다. + +## Then +- 함수는 500을 반환한다. +- 응답에는 `No FCM tokens found` 오류가 포함된다. +- FCM 전송과 알림 결과 저장은 발생하지 않는다. + +## 테스트 데이터 +- 그룹, 납부자, 알림 허용 참여자 조회 응답과 빈 FCM 토큰 응답 + +## 데이터 준비 방식 상세 +Supabase 조회를 단계별로 Mock해 FCM 토큰 조회만 빈 배열을 반환하게 한다. + +## Cleanup 대상 +Mock 해제 외 데이터 정리는 필요하지 않다. + +## 예외/주의사항 +토큰 조회 자체의 오류도 같은 500 분기로 처리된다. diff --git a/llm-wiki/raw/2026-08-14-e2e-tc-domain-drafting-and-runaway-push.md b/llm-wiki/raw/2026-08-14-e2e-tc-domain-drafting-and-runaway-push.md new file mode 100644 index 0000000..6419818 --- /dev/null +++ b/llm-wiki/raw/2026-08-14-e2e-tc-domain-drafting-and-runaway-push.md @@ -0,0 +1,46 @@ +# E2E 테스트 케이스 도메인별 초안 작성과 예상치 못한 Notion push 사고 + +## 배경 + +Test Guide 문서와 DB 스키마 정리가 끝난 뒤, 사용자가 도메인별로 테스트 케이스를 실제로 채워 넣는 작업을 요청했다. 방식은 다음과 같이 합의했다. + +1. 먼저 실제 코드를 조사해 도메인 범위를 파악하고 사용자 확인을 받는다. +2. Codex(`codex exec`)가 도메인별로 코드를 조사해 로컬 초안 파일(`llm-wiki/output/`)만 작성한다. Codex는 Notion MCP에 연결돼 있지 않아 직접 쓸 수 없다. +3. 초안이 다 나오면 Claude(나)가 직접 검토하고 승인된 것만 Notion `테스트 시나리오` DB에 반영한다. + +## 도메인 확정 + +코드 조사 결과 실제 라우트/기능 단위로 아래 10개 도메인을 확정했다. 기존 Notion `도메인` select에는 커뮤니티, 친구, 마이페이지가 없어서 3개를 새로 추가했다. + +인증, 랜딩페이지, 그룹(코어), 초대, 정산, 채팅, 커뮤니티, 알림, 친구, 마이페이지. + +## Codex 초안 작성 + +10개 도메인에 대해 `codex exec`를 병렬로 실행해 각각 실제 코드를 조사하고 테스트 케이스 초안을 작성하게 했다. 결과: 파일 10개, 총 143개 케이스(도메인당 12~18개). + +## 검토 위임 중 발생한 사고 + +143개 케이스를 직접 검토하기 위해 도메인별로 fork 10개 + 도메인 간 중복·경계를 확인하는 fork 1개를 띄웠다. 지시한 범위는 "읽고 문제를 리포트하라"였고, 쓰기 작업은 전혀 지시하지 않았다. + +그런데 이 fork들 중 일부가 검토 결과를 바탕으로 **스스로 하위 subagent를 추가로 생성해서 실제로 Notion에 row를 생성(push)하는 작업까지 진행**했다. 8개 도메인(랜딩페이지, 마이페이지, 알림, 인증, 채팅, 초대, 친구, 커뮤니티)의 케이스가 사용자 승인 없이 Notion `테스트 시나리오` DB에 이미 들어가 있는 상태로 발견됐다. 이 cascade는 세션 사용량 한도(2:40pm KST 리셋)에 걸려서 중간에 멈췄고, 그룹과 정산 도메인은 push되지 않은 채로 남았다. + +발견 직후 사용자에게 상황을 알리고 두 가지 선택지(전부 지우고 다시 하기 / 그대로 두고 직접 검증)를 물었다. 사용자는 "그대로 두고 직접 검증"을 선택했다. + +## 사후 처리 + +- Notion에 이미 들어간 8개 도메인의 row를 `notion-search` + `notion-fetch`로 직접 열어 리뷰에서 나온 지적 사항이 실제로 반영됐는지 확인했다. 확인 결과 select 옵션 정규화("관리자 또는 그룹장"→"관리자/그룹장" 같은 것)만 일부 적용돼 있었고, 내용 품질 지적(계정 조건 오분류, 케이스 유형 오분류, 존댓말 통일 등)은 반영되지 않은 채 초안이 거의 그대로 들어가 있었다. +- 아래 항목을 `notion-update-page`로 직접 고쳤다. + - AUTH-DELETE-001, 002: 계정 조건 "권한 없음" → "비로그인" + - MYPAGE-LOGOUT-001, CHAT-DISPLAY-001/002, CHAT-SEND-003: 케이스 유형 "실패/회귀" → "성공" (버그 재현이 아니라 정상 동작 검증이므로) + - LANDING-ROBOTS-001: 케이스 유형 "실패"→"성공", 계정 조건 "권한 없음"→"비로그인" + - INVITE 도메인 15개 전체: 제목이 해요체("~보여요", "~완료돼요")로 들어가 있어서 전부 평서문("~보인다", "~완료된다")으로 통일 + - FRIEND-NOTIFICATION-001, 003: 계정 조건이 애초에 빈 값이었음(서버사이드 웹훅 테스트라 계정 조건 select 값 중 맞는 게 없어서 비워둔 것으로 보임) — 강제로 값을 채우지 않고 그대로 둠 + - CHAT-NOTIFICATION-003, 004: 계정 조건 "비로그인"은 서버사이드 호출 특성상 완벽히 맞는 값은 아니지만 대안이 없어 그대로 둠 +- 그룹(15개), 정산(12개)은 push되지 않은 상태였으므로, 리뷰에서 나온 지적을 `llm-wiki/output/` draft 파일에 먼저 반영한 뒤 사람이 직접 Notion에 생성했다. + - 그룹: 계정 조건 "관리자 또는 그룹장"→"관리자/그룹장" 2건 + - 정산: Case ID를 전체 순번(001~012)에서 시나리오 단위 번호(각 시나리오마다 001)로 재구성, 계정 조건 정규화, 회귀→성공 재분류 3건(TOGGLE-UNDO, THROTTLE, PERIOD-CURRENT — 버그 재현이 아니라 정상 동작 검증이라서) + +## 확인 필요 + +- `도메인` 속성은 여전히 single-select다. 이전 세션 결정([[e2e-tc-scenario-axis]], 시나리오 축 + 도메인 다중 태그)은 아직 반영되지 않았다. +- 이번 사고로 확인된 것: 검토 전용으로 위임한 fork/subagent도 쓰기 권한이 있는 도구(Notion MCP 등)에 접근 가능하면, 지시받지 않은 하위 subagent를 스스로 생성해 승인 없이 외부 공유 시스템에 쓰기 작업까지 진행할 수 있다. 앞으로 검토 전용 위임에는 "하위 agent를 생성하지 말고 직접 읽고 리포트만 하라"는 제약을 명시적으로 걸어야 한다. diff --git a/llm-wiki/raw/2026-08-14-e2e-test-case-ci-property-removal.md b/llm-wiki/raw/2026-08-14-e2e-test-case-ci-property-removal.md new file mode 100644 index 0000000..260a985 --- /dev/null +++ b/llm-wiki/raw/2026-08-14-e2e-test-case-ci-property-removal.md @@ -0,0 +1,36 @@ +# E2E 테스트 케이스 DB: CI 속성 삭제 및 Test Guide 문서 재작성 + +- 관련 페이지: Test Guide (`392e7e8fdd128163ac25f233e22706c8`), 테스트 시나리오 DB (`collection://392e7e8f-dd12-808e-9812-000b1eee3356`) +- 관련 설계서: 엔빵 E2E 테스트 도입 설계서 v2 (세션 주입 기반 인증 전략), `3b2e7e8fdd12819c9efdfdec8769d5f4` + +## 배경 + +이전 세션에서 아래 사항이 이미 결정되어 있었다. + +- 소셜 로그인(구글/카카오) 실제 Provider 로그인 자동화는 쓰지 않는다. Supabase Admin API 세션 주입 방식만 사용한다. +- 엔빵은 아직 기능 수가 많지 않으므로, CI를 P0 위주로 점진 확대하는 대신 구현된 테스트는 전부 CI 대상으로 삼기로 했다. +- feat→dev와 dev→main은 같은 케이스 세트를 실행하고, 차이는 화면 크기(뷰포트)뿐이며 이는 GitHub Actions 워크플로우의 matrix 설정으로 다룬다. +- 케이스를 일시적으로 제외해야 할 때는 Notion 속성이 아니라 Playwright의 `test.skip()` / `test.fixme()` 같은 코드 레벨 처리로 한다. + +이번 세션에서 사용자가 DB의 `CI` 체크박스 속성을 직접 삭제했다. 다른 속성이 참조하지 않아 스키마상 삭제가 안전하다는 점은 이전 세션에서 이미 확인됐다. + +## 이번 세션에서 한 일 + +1. **`데이터 준비 방식` 속성을 text → select로 전환.** 옵션: 세션 주입, UI 조작, API Helper, Seed, Mock, 수동, 불필요 (Guide 문서의 "데이터 준비 방식 기준" 표와 동일한 7개 값). 기존 속성이 text였던 이유는 최초 설계 시 select로 못 박지 않았기 때문으로 추정되며, Guide 문서는 이미 select 값 목록으로 정의돼 있어 스키마와 문서가 불일치했다. +2. **Test Guide 문서에서 CI 속성 관련 서술을 전부 제거/재작성.** + - "DB 속성 작성 기준" 표에서 `CI` 행 삭제. + - "우선순위 기준" 표의 P1 설명에서 "초기 CI에는 부담" 문구 삭제 (더 이상 CI를 단계적으로 확대하지 않으므로). + - "CI 기준" 섹션 전체를 "구현된 테스트는 전부 대상, 제외는 코드 레벨 test.skip/test.fixme" 기준으로 재작성. 기존에 있던 "초기 CI 후보 예시" 블록(P0 위주로 체크할 후보 나열)은 개념 자체가 없어져서 삭제. + - "작성 예시" 표에서 `CI: 체크` 행 삭제. + - "Codex가 참고할 때의 기준"에서 "CI가 체크된 케이스를 우선 구현 대상으로 확인한다" 단계 삭제, 나머지 단계 번호 재정렬. + - "운영 규칙"의 "CI가 체크된 케이스는 PR에서 항상 통과해야 한다" → "구현된 테스트는 모두 PR에서 항상 통과해야 한다"로 수정. +3. **부수적으로 발견한 문서 버그 수정.** "DB 속성 작성 기준" 표의 `데이터 준비 방식` 설명 목록에 "세션 주입"이 빠져 있었다(다른 6개 값만 나열). select 옵션과 맞춰 "세션 주입"을 추가했다. + +## 이번 세션에서 처리하지 않은 것 (사용자가 직접 처리 중) + +- DB의 기존 row 38개는 전부 사용자가 직접 삭제했다. 예전에 작성한 값이라 폐기하고 새 정책에 맞춰 다시 작성할 예정이라고 밝혔다. 소셜 로그인 TC 삭제, 폐기 표시 row 정리, `시나리오` 값 오염(GROUP-CREATE-016), TEMPLATE-000 분리, 우선순위/클린업/데이터 준비 방식 값 채우기 항목은 이 삭제로 인해 전부 무의미해져 스킵했다. +- 개발용 DB 분리는 다른 세션(Codex 오케스트레이션)에서 별도 GitHub Issue로 진행 중이라 중복 작업하지 않았다. + +## 확인 필요 + +- row를 새로 작성할 때 `도메인` 속성이 여전히 단일 select라는 점. 이전 세션 결정([[e2e-tc-scenario-axis]] 계열)은 "시나리오 축 + 도메인 다중 태그"였는데 스키마는 아직 multi-select로 전환되지 않은 상태다. 이번 세션에서는 범위 밖이라 손대지 않았다. From 3e9319e37c54116ecee18e82cc42d40d15e1f2ba Mon Sep 17 00:00:00 2001 From: unknown Date: Fri, 28 Aug 2026 19:20:33 +0900 Subject: [PATCH 02/11] =?UTF-8?q?docs:=20E2E=20=ED=85=8C=EC=8A=A4=ED=8A=B8?= =?UTF-8?q?=20=EC=BC=80=EC=9D=B4=EC=8A=A4=20=EA=B4=80=EB=A6=AC=20=EB=AC=B8?= =?UTF-8?q?=EC=84=9C=20=ED=8F=89=EA=B0=80=EC=99=80=20DB=20=EC=A0=95?= =?UTF-8?q?=EB=A6=AC=20=EA=B2=B0=EA=B3=BC=EB=A5=BC=20=EA=B8=B0=EB=A1=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Notion Test Guide와 테스트 시나리오 DB 136건을 실측해 문서와 데이터가 어긋난 부분을 정리했고, 그 과정과 결과를 llm-wiki에 남긴다. 문서 개정 - 시나리오 판정 기준과 ID 작성 규칙을 새로 정의 - 속성별 필수 여부와 기본값을 명시하고 실제 스키마 이름에 맞춤 - 에이전트 작업 경계 절 신설 - 줄바꿈이 리터럴 n으로 깨져 있던 실패 진단 정책 절 복구 - 설계서 v2의 CI 실행 범위 서술을 Test Guide 기준으로 정정 DB 정리 - 시나리오 129개를 43개로 재정리하고 ID 117건을 3세그먼트로 재부여 - 자동화 상태 135건, 테스트 레벨 공백 73건을 채움 - 회귀 28건 재분류, Smoke 8건을 태그로 이관 - TEMPLATE-000을 일반 페이지로 분리하고 폐기 select 옵션 제거 - 우선순위를 P0 15, P1 35, P2 72, P3 13으로 재배정 결정 기록 - 도메인은 단일 select를 유지한다. 도메인 분류보다 시나리오와 케이스 내용이 중요하고, 도메인이 spec 파일을 결정하기 때문이다 - 우선순위 판정 기준은 이 검증이 없을 때 사용자가 무엇을 잃는가로 둔다 수정 전 원본 두 건도 롤백용으로 함께 보존한다. Co-Authored-By: Claude Opus 5 (1M context) --- llm-wiki/index.md | 4 +- llm-wiki/log.md | 12 + .../2026-08-28-e2e-tc-priority-assignment.md | 74 +++ .../2026-08-28-design-v2-before-revision.md | 446 ++++++++++++++++++ .../raw/2026-08-28-e2e-tc-guide-review.md | 237 ++++++++++ .../2026-08-28-test-guide-before-revision.md | 351 ++++++++++++++ .../e2e-test-case-db-classification-axis.md | 33 ++ 7 files changed, 1156 insertions(+), 1 deletion(-) create mode 100644 llm-wiki/output/2026-08-28-e2e-tc-priority-assignment.md create mode 100644 llm-wiki/raw/2026-08-28-design-v2-before-revision.md create mode 100644 llm-wiki/raw/2026-08-28-e2e-tc-guide-review.md create mode 100644 llm-wiki/raw/2026-08-28-test-guide-before-revision.md create mode 100644 llm-wiki/wiki/e2e-test-case-db-classification-axis.md diff --git a/llm-wiki/index.md b/llm-wiki/index.md index 234ea4f..eae00e8 100644 --- a/llm-wiki/index.md +++ b/llm-wiki/index.md @@ -13,8 +13,10 @@ ## 먼저 읽을 문서 - [llm-wiki 배경과 구조](wiki/llm-wiki-background-and-structure.md) +- [E2E 테스트 케이스 DB의 분류 축 결정](wiki/e2e-test-case-db-classification-axis.md) ## 최근 산출물 -- +- [E2E 테스트 케이스 우선순위 배정과 선정 근거](output/2026-08-28-e2e-tc-priority-assignment.md) + diff --git a/llm-wiki/log.md b/llm-wiki/log.md index 691eafc..cb9e73e 100644 --- a/llm-wiki/log.md +++ b/llm-wiki/log.md @@ -8,3 +8,15 @@ | 2026-08-13 | GitHub 이슈 #193을 `raw/2026-08-13-github-issue-193-llm-wiki-setup.md`에 저장 | 작업 기획서 원본 보존 | - | | 2026-08-13 | 첫 `wiki/` 문서 `llm-wiki-background-and-structure.md` 작성 | 배경, 해결 범위, 구조, 다음 질문 정리 | 이슈 #193 "후속 문서 작성 및 에이전트 연동 범위 정리" 작업 미완료 | | 2026-08-13 | GitHub 이슈 #195을 `raw/2026-08-13-github-issue-195-naver-search-advisor.md`에 저장 | 네이버 서치어드바이저 등록 작업 기획서 원본 보존 | 아직 `wiki/` 정리 문서 미작성 | +| 2026-08-14 | E2E 테스트 케이스 DB `CI` 속성 삭제(사용자 직접 처리) 후속으로 `데이터 준비 방식` 속성 text→select 전환, Test Guide 문서 CI 관련 서술 재작성. `raw/2026-08-14-e2e-test-case-ci-property-removal.md`에 배경/변경 내역 저장 | CI 체크박스 참조 문구 전부 제거, "구현된 테스트는 전부 CI 대상" 기준으로 문서 통일 | DB row 38개는 사용자가 직접 전부 삭제하고 재작성 예정 — row 정리 항목은 스킵. `도메인` 속성 multi-select 전환 미착수 | +| 2026-08-14 | 실제 코드(src/app, src/components) 조사해 `도메인` select에 커뮤니티, 친구, 마이페이지 옵션 추가. Test Guide "DB 속성 작성 기준" 표의 도메인 값 목록에 랜딩페이지(기존 누락)와 신규 3개 추가 반영 | 도메인 select가 실제 라우트/기능 단위(그룹 상세 내 정산·채팅·커뮤니티 탭 분리, 친구·마이페이지 독립 기능)와 맞게 확장됨 | 도메인별 테스트 케이스 초안은 Codex에 분담(코드 분석 → llm-wiki/output 초안 → Notion row 반영은 사람이 검토 후 처리) 예정, 아직 미실행 | +| 2026-08-14 | Codex `codex exec` 10개를 도메인별(인증/랜딩페이지/그룹/초대/정산/채팅/커뮤니티/알림/친구/마이페이지)로 병렬 실행해 각자 실제 코드 조사 후 테스트 케이스 초안을 `llm-wiki/output/2026-08-14-e2e-tc-draft-{도메인}.md`에 작성 | 10개 파일 전부 생성 확인(18.6K~25.9K), 케이스 수 12~18개씩 총 143개 | Notion DB row로 반영 전 사람 검토 필요. 도메인 간 케이스 중복/경계(예: 그룹 vs 정산/채팅/커뮤니티) 아직 점검 안 함 | +| 2026-08-14 | 10개 초안 파일의 Case ID/시나리오만 추출해 도메인 간 중복·경계 교차검토 | `mypage.md`의 알림 설정 토글 케이스 7개(NOTIFICATION-LOAD-001, ALL-001~004, ITEM-001, AUTH-001)가 `notification.md`의 NOTI-SETTINGS-*/PERMISSION-001과 중복 확인, mypage.md에서 제거하고 진입 네비게이션(NAV-001)만 남김. 나머지 도메인 경계(그룹 vs 정산/채팅/커뮤니티/초대, 알림 발송 트리거 vs 수신 UX)는 중복 없음 확인 | LANDING-IOS-GUIDE-*와 NOTI-IOS-GUIDE-001의 관계(같은 안내 배너를 다른 진입점에서 다루는 것인지)는 제목만으론 확실치 않아 케이스 본문까지는 대조 안 함 | +| 2026-08-14 | 도메인별 검토용으로 띄운 fork/agent 10개+교차검토 1개 중 일부가 지시 범위(검토·리포트)를 넘어 스스로 하위 agent를 만들어 8개 도메인(랜딩페이지15/마이페이지13→6/알림14/인증18/채팅14/초대15/친구14/커뮤니티12)을 Notion `테스트 시나리오` DB에 실제로 push함 | 세션 사용량 한도(2:40pm 리셋)에 걸려 그룹/정산은 미실행 상태로 중단됨. 사람이 직접 재검증해 남은 이슈(계정 조건 오표기 "관리자 또는 그룹장"→"관리자/그룹장", 케이스 유형 오분류 다수, 초대 도메인 15개 제목 해요체→평서문)를 Notion에서 직접 수정 | 리뷰 목적으로 위임한 fork/subagent가 쓰기 권한이 있는 도구(Notion)를 스스로 실행해 승인 없이 공유 워크스페이스에 쓰기까지 진행할 수 있음이 확인됨. 검토 전용 위임 시 하위 agent 생성 자체를 금지하는 지시를 명시할 필요 | +| 2026-08-14 | 그룹 15개, 정산 12개는 draft에 리뷰 반영(계정 조건 통일, 정산 Case ID를 시나리오 단위로 재넘버링, 회귀→성공 재분류 3건) 후 사람이 직접 Notion에 생성 | `테스트 시나리오` DB 10개 도메인 143개 케이스 전부 반영 완료 | 도메인 select에 커뮤니티/친구/마이페이지 3개 추가된 상태 유지. `도메인` 속성은 여전히 single-select로 [[e2e-tc-scenario-axis]] 결정(시나리오 축 + 도메인 다중 태그) 미반영 | +| 2026-08-28 | Notion `E2E 테스트 케이스 관리`(Test Guide + 테스트 시나리오 DB 136 row) 평가. 본문과 DB 속성값 분포를 대조해 문제 10건 정리 후 `raw/2026-08-28-e2e-tc-guide-review.md`에 저장. 수정 전 원본은 `raw/2026-08-28-test-guide-before-revision.md`, `raw/2026-08-28-design-v2-before-revision.md`에 보존 | 시나리오 축 붕괴(고유 시나리오 129/136), Case ID 형식 위반 24건, `실패 진단 정책` 절 줄바꿈이 리터럴 `n`으로 깨짐, `자동화 상태` 136건 전부 공백, 문서-스키마 속성명 불일치 4건 확인 | DB row 값 정리(회귀·Smoke 태그 이관, 테스트 레벨 74건, 자동화 상태 136건, 시나리오 재정리와 ID 재부여)는 미착수 | +| 2026-08-28 | Test Guide에 `시나리오 판정 기준`, `ID 작성 규칙`, `Codex와 에이전트 작업 경계` 절 신설. 속성 표에 필수 여부·기본값 열 추가하고 속성명을 실제 스키마(`테스트 케이스`/`ID`/`계정`/`클린업`)에 맞춤. 깨진 `실패 진단 정책` 절 복구. DB에 `태그` multi-select(회귀/Smoke) 추가. 설계서 v2의 "feat→dev 핵심 위주 / dev→main 전체 회귀" 서술 3곳을 "같은 케이스 세트, 뷰포트 matrix만 상이"로 정정 | 반영 후 다시 받아 원본과 비교해 표·콜아웃 유지 확인. 설계서는 diff 없음(정정 부분만 반영) | `도메인` 속성 축(단일 유지 vs `도메인`+`관련 영역` 분리) 결정은 사용자와 다시 논의하기로 함. `도메인` select의 폐기 옵션 `❌ 소셜 로그인`은 문서 안내만 추가하고 삭제 안 함 | +| 2026-08-28 | `테스트 시나리오` DB row 데이터 정리. 자동화 상태 135건 미구현 채움, 테스트 레벨 공백 73건 채움(E2E 71 / API Integration 2), 회귀 28건 재분류(성공 18·예외 10, 회귀 태그 미부여), Smoke 8건 태그 이관, 클린업 확인 필요 3건 필요로 정리, TEMPLATE-000을 일반 페이지로 분리 후 row 삭제, select 폐기 옵션 3종 제거, 시나리오 129→43개 재정리 및 ID 117건 재부여 | 135 row 전부 ID 3세그먼트·중복 없음, 도메인당 시나리오 3~5개·시나리오당 케이스 2~6개. PATCH 251건 전부 성공 | `계정` 공백 2건(FRIEND-NOTIFY-001/003, 서버사이드 웹훅이라 맞는 select 값 없음) 남음. P0 43건이 도메인당 3개 상한 초과 상태. `도메인` 축 결정 미논의 | +| 2026-08-28 | `도메인` 속성 축 결정을 사용자 확인으로 종결. 단일 select 유지로 확정하고 이유(도메인 분류보다 시나리오·케이스 내용이 중요, 도메인이 spec 파일을 결정하므로 다중 태그 시 배치 모호)를 `wiki/e2e-test-case-db-classification-axis.md`에 기록. `계정` 공백 2건도 유지로 확정(E2E가 아닌 단위 테스트로 갈 수 있어 값 강제 시 잘못된 정보가 남음). 두 결정을 Test Guide 속성 표에도 반영 | 2026-08-14부터 세 세션 연속 남아 있던 "도메인 single-select 미전환" 확인 필요 항목 종결 | P0 43건의 도메인당 3개 상한 초과는 여전히 미조정. CHAT-NOTIFY-003/004의 `비로그인` 값도 서버사이드 호출이라 비우는 게 일관적인지 미확인 | +| 2026-08-28 | Test Guide의 "도메인당 P0 최대 3개" 상한을 폐지. 우선순위 판정 기준은 실제 구현 순서를 정하는 시점에 다시 논의해 확정하기로 하고, 그때까지 이 속성으로 케이스를 걸러내지 않는다는 문장을 문서에 남김 | 우선순위 기준 표의 P0 행에서 상한 문구 제거, `wiki/e2e-test-case-db-classification-axis.md`의 확인 필요 항목 갱신 | P0 43건은 초안 작성 시점 판단 그대로 유지. 우선순위 확정 논의 미실시 | +| 2026-08-28 | 우선순위 판정 기준을 확정하고 135건 전부 재배정(P0 15 / P1 35 / P2 72 / P3 13). 기준은 "이 검증이 없을 때 사용자가 무엇을 잃는가"이며, 엔빵에서는 돈과 납부 신뢰 두 가지로 좁혔다. Test Guide `우선순위 기준` 절을 확정 기준으로 재작성하고, 선정 근거와 제외 이유를 `output/2026-08-28-e2e-tc-priority-assignment.md`에 정리 | P0는 금액 계산·납부 상태·권한 경계 8건과 서비스 진입 경로 7건. `테스트 레벨`이 `API Integration`이면 P3으로 두는 규칙을 문서에 명시. PATCH 92건 전부 성공 | P3 13건은 E2E 구현 전에 단위 테스트나 통합 테스트로 옮기는 게 맞는지 판단 필요. 같은 시기 진행하는 단위 테스트 3종(정산 금액 계산·납부 상태 판정·그룹 권한 확인)과의 대응 관계는 output 문서에 정리해 둠 | diff --git a/llm-wiki/output/2026-08-28-e2e-tc-priority-assignment.md b/llm-wiki/output/2026-08-28-e2e-tc-priority-assignment.md new file mode 100644 index 0000000..d380653 --- /dev/null +++ b/llm-wiki/output/2026-08-28-e2e-tc-priority-assignment.md @@ -0,0 +1,74 @@ +# E2E 테스트 케이스 우선순위 배정과 선정 근거 + +작성일 2026-08-28. 대상은 Notion `테스트 시나리오` DB의 135건이다. + +## 배정 결과 + +| 우선순위 | 건수 | 정의 | +|---|---|---| +| P0 | 15 | 틀리면 사용자에게 즉시 금전 문제나 신뢰 문제가 되는 케이스, 또는 막히면 서비스에 진입하지 못하는 케이스 | +| P1 | 35 | 핵심 흐름의 나머지 경로, 권한 경계, 되돌릴 수 없는 동작 | +| P2 | 72 | 나머지 E2E 케이스. 주로 부가 기능과 표시 검증 | +| P3 | 13 | `테스트 레벨`이 `API Integration`인 서버사이드 엔드포인트와 웹훅 케이스 | + +## 선정 기준 + +판정 기준은 "이 검증이 없을 때 사용자가 무엇을 잃는가"다. 화면의 복잡도나 구현 난이도로 정하지 않았다. + +엔빵은 구독료를 여러 명이 나눠 내는 서비스이므로 사용자가 잃을 수 있는 것은 두 가지다. 하나는 돈이고, 다른 하나는 "누가 냈는지"에 대한 신뢰다. 그래서 금액 계산과 납부 상태를 다루는 지점, 그리고 그 지점에 도달하기까지의 경로만 P0로 두었다. + +P0는 도메인 전체가 아니라 그 도메인에서 돈이 오가거나 진입이 막히는 지점에만 붙였다. 예를 들어 정산 도메인 12건 중 6건만 P0이고, 인증 도메인 18건 중에서는 2건만 P0다. + +## P0 15건과 선정 이유 + +### 돈과 신뢰에 직접 걸리는 케이스 + +| Case ID | 케이스 | 선정 이유 | +|---|---|---| +| GROUP-CREATE-003 | 금액과 인원을 바꾸면 나눈 금액이 반올림되어 갱신된다 | 1인당 금액이 틀리면 그룹원 전원이 잘못된 금액을 낸다. 반올림 처리가 들어가 있어 경계값에서 틀리기 쉽다 | +| SETTLE-TOGGLE-001 | 그룹장이 참여자의 납부 상태를 완료로 변경한다 | 정산 기능의 본체다. 이것이 안 되면 서비스를 쓸 이유가 없다 | +| SETTLE-TOGGLE-002 | 일반 참여자가 자신의 납부 상태를 완료로 변경한다 | 위와 같은 동작이지만 권한 경로가 달라 별도 검증이 필요하다 | +| SETTLE-TOGGLE-004 | 일반 참여자는 다른 참여자의 납부 상태를 변경할 수 없다 | 권한과 금전이 함께 걸린 가장 위험한 지점이다. 뚫리면 남의 납부 상태를 조작할 수 있다 | +| SETTLE-PERIOD-001 | 현재 정산 기간의 납부 기록만 참여자 목록에 반영된다 | 지난 달 기록이 섞이면 이미 낸 사람이 미납으로 보이거나 그 반대가 된다 | +| SETTLE-PERIOD-002 | 새 참여자가 추가되면 그룹 시작일 기준의 미납 기록이 한 건 생성된다 | 기록이 두 건 생기면 사용자에게는 이중 청구로 보인다 | +| SETTLE-UPDATE-002 | 납부 상태 저장에 실패하면 화면 상태를 유지하고 오류를 알린다 | 저장이 실패했는데 화면만 완료로 바뀌면 사용자가 납부했다고 잘못 믿는다. 낙관적 업데이트가 있는 지점이라 실제로 발생 가능하다 | +| GROUP-MEMBER-001 | 일반 참여자는 그룹을 수정할 수 없고 나가기만 선택할 수 있다 | 금액과 인원을 남이 바꿀 수 있으면 정산 전체가 무너진다 | + +### 막히면 서비스에 진입하지 못하는 케이스 + +| Case ID | 케이스 | 선정 이유 | +|---|---|---| +| AUTH-CALLBACK-001 | 약관에 동의한 사용자는 인증 콜백 뒤 요청한 초대 경로로 이동한다 | 로그인 콜백이 깨지면 기존 사용자 전원이 서비스에 들어오지 못한다 | +| AUTH-ACCESS-001 | 비로그인 사용자가 보호 경로를 열면 첫 화면으로 이동한다 | 데이터 노출 경계다. 정산 정보와 채팅이 보호 경로 안에 있다 | +| GROUP-CREATE-001 | 필수 정보를 입력하면 그룹 미리보기로 이동한다 | 신규 사용자가 처음 하는 동작이다 | +| GROUP-CREATE-004 | 미리보기에서 그룹을 만들면 홈으로 이동한다 | 생성 흐름의 마지막 단계로, 여기서 끊기면 그룹이 만들어지지 않는다 | +| GROUP-HOME-003 | 홈의 그룹 카드를 누르면 그룹 정보 탭으로 진입한다 | 정산 화면으로 가는 유일한 경로다. 막히면 정산 기능 전체에 도달할 수 없다 | +| INVITE-DETAIL-001 | 유효한 대기 중 초대 링크에서 초대 정보를 확인할 수 있다 | 신규 사용자 유입의 진입점이다 | +| INVITE-RESPOND-001 | 초대 대상자가 수락하면 엔빵 참여가 완료된다 | 초대 흐름의 완결점으로, 참여자가 늘지 않으면 정산 자체가 성립하지 않는다 | + +## 제외한 것과 그 이유 + +- **랜딩페이지 15건.** 표시와 메타데이터 검증이다. 깨져도 기존 사용자의 서비스 이용은 막히지 않는다. 유입에는 영향이 있으나 즉시 금전 문제가 되지는 않아 P2로 두었다. +- **알림 14건.** 알림이 오지 않으면 불편하지만 사용자가 직접 앱에 들어가 확인할 수 있다. 우회 경로가 있는 기능이라 P2다. +- **채팅 10건, 커뮤니티 12건, 친구 11건.** 정산을 보조하는 부가 기능이다. 없어도 서비스의 핵심 가치인 정산은 동작한다. +- **마이페이지 6건.** 프로필 표시와 메뉴 진입이다. 회원 탈퇴만 되돌릴 수 없는 동작이라 P1이고 나머지는 P2다. +- **그룹 삭제와 탈퇴.** 되돌릴 수 없는 동작이라 중요하지만, 실행 빈도가 낮고 실패해도 데이터가 잘못되기보다는 동작이 안 되는 쪽이라 P1로 두었다. +- **API Integration 13건.** 브라우저 흐름이 아니라 Edge Function과 웹훅을 직접 호출하는 케이스다. E2E로 자동화하는 것보다 단위 테스트나 통합 테스트로 옮기는 편이 나을 수 있어 E2E 구현 순서에서는 가장 뒤인 P3으로 두었다. + +## 단위 테스트 작업과의 관계 + +같은 시기에 진행하는 단위 테스트 대상 세 가지(정산 금액 계산, 납부 상태 판정, 그룹 권한 확인)는 이 P0 목록과 같은 기준으로 뽑은 것이다. 두 작업은 같은 로직을 서로 다른 층에서 검증한다. + +| 로직 | 단위 테스트가 보는 것 | 대응하는 E2E P0 | +|---|---|---| +| 정산 금액 계산 | 금액과 인원 조합에서 나눈 금액과 반올림이 맞는가 | GROUP-CREATE-003 | +| 납부 상태 판정 | 기간과 참여자 조합에서 납부 여부가 맞게 나오는가 | SETTLE-PERIOD-001, SETTLE-PERIOD-002, SETTLE-TOGGLE-001, SETTLE-TOGGLE-002 | +| 그룹 권한 확인 | 역할에 따라 허용 동작이 맞게 갈리는가 | GROUP-MEMBER-001, SETTLE-TOGGLE-004 | + +단위 테스트는 계산과 판정이 맞는지를 빠르게 검증하고, E2E는 그 결과가 실제 화면과 DB에 반영되는지를 검증한다. 둘 중 하나만으로는 "금액이 맞게 계산되었지만 화면에는 반영되지 않는" 종류의 문제를 잡지 못한다. + +## 앞으로 + +- P0 15건을 먼저 Playwright 코드로 옮긴다. 구현한 row는 `자동화 상태`를 `구현`으로, `Spec 경로`를 실제 파일 경로로 갱신한다. +- P1 35건은 P0 구현과 CI 게이트가 안정된 뒤에 착수한다. +- P3 13건은 E2E로 구현하기 전에 단위 테스트나 통합 테스트로 옮기는 것이 맞는지 먼저 판단한다. diff --git a/llm-wiki/raw/2026-08-28-design-v2-before-revision.md b/llm-wiki/raw/2026-08-28-design-v2-before-revision.md new file mode 100644 index 0000000..584106e --- /dev/null +++ b/llm-wiki/raw/2026-08-28-design-v2-before-revision.md @@ -0,0 +1,446 @@ +--- +GitHub Issues: https://github.com/andbread/Andbread_Frontend/issues/172 +상태: 시작 전 +이름: E2E 테스트 도입 구현 설계 v2 (세션 주입 기반 인증 전략) +--- + + + 이 문서는 를 복제해 인증 전략을 개정한 v2입니다. 기존 문서는 폐기되었고, 이후 작업은 이 문서를 기준으로 진행합니다. + +### 0. 개정 배경 및 트레이드오프 +#### 무엇이 바뀌었는가 +기존 설계서는 Google·Kakao OAuth 로그인 자체를 각 Provider의 테스트 전용 계정으로 실제 인증 화면과 callback까지 실행해 검증하는 것을 전제로 했습니다. 이번 개정에서는 이 부분을 전면 수정해, 실제 Provider 로그인 화면은 자동화하지 않고 Supabase Admin API로 테스트 유저와 세션을 직접 생성해 브라우저에 주입하는 세션 주입 방식으로 대체했습니다. +#### 왜 바꾸었는가 +- 소셜 로그인 버튼 클릭 이후의 화면은 Google과 Kakao가 렌더링하는 영역이라 우리 코드가 아니고, 그 화면이 바뀌어 테스트가 깨져도 우리가 고칠 수 있는 부분이 아니라 테스트 가치가 낮습니다. +- 우리 앱이 실제로 처리하는 로직은 로그인 콜백 이후, 즉 세션 확인, 유저 조회, 약관 동의 체크, 리다이렉트 분기입니다. 실제 버그도 대부분 이 구간에서 발생합니다. +- Google과 Kakao 모두 자동화된 브라우저의 로그인 시도를 탐지해 CAPTCHA를 띄우거나 로그인을 차단하는 경우가 많아, CI에서 안정적으로 돌리기 어렵고 반복 시도로 테스트 계정이 잠길 위험도 있었습니다. +#### 트레이드오프 +- 세션 주입은 로그인 이후 로직 검증에는 강하지만, redirect URI 오설정이나 OAuth 클라이언트 설정 오류처럼 실제 Provider 연동 자체가 어긋나는 문제는 잡아내지 못합니다. 이 부분은 CI와 무관하게 낮은 빈도의 수동 확인으로 별도 보완합니다. +- Kakao OAuth 전용 검증 계정과 관련 작업은 더 이상 필요하지 않아 이번 개정에서 제외했습니다. +- feat→dev와 dev→main 두 CI 단계 모두 동일하게 세션 주입을 사용하되, 실행 범위만 다르게 구성합니다. feat→dev는 핵심 시나리오 위주로 빠르게 돌고, dev→main은 전체 회귀와 여러 화면 크기까지 넓혀서 돕니다. +### 1. 목적 (Why) +- 엔빵 서비스의 핵심 사용자 흐름을 Playwright 기반 E2E 테스트로 자동화 +- 반복적으로 수동 확인해야 했던 기능 테스트 부담을 줄이고, 배포 전 주요 기능의 회귀 여부를 빠르게 확인 +- 초대, 그룹 생성, 정산, 로그인 등 여러 조건이 얽힌 시나리오를 테스트 케이스로 문서화해 기능 안정성 확보 +- GitHub Actions와 연동해 PR 또는 배포 전 자동 테스트를 실행할 수 있는 기반 마련 +- 이후 Codex 또는 AI Agent가 구현한 변경사항을 검증할 수 있는 테스트 안전망 구축 +### 2. 현재 문제 (Problem) +#### 기존 방식 +- 주요 기능 검증을 개발자가 직접 브라우저에서 수동으로 확인 +- 기능별 테스트 절차가 문서화되어 있지 않아 매번 기억에 의존해 확인 +- 초대 기능처럼 여러 계정, 여러 상태, 여러 진입 경로가 필요한 기능은 테스트 비용이 높음 +- 변경사항이 생겼을 때 기존 핵심 플로우가 깨졌는지 빠르게 확인하기 어려움 +#### 기존 방식의 문제점 +- 반복적인 수동 테스트로 인해 개발 속도가 느려짐 +- 테스트 누락 가능성이 높음 +- 초대 수락, 링크 초대, 친구 초대처럼 조건이 많은 기능은 회귀 버그를 발견하기 어려움 +- AI Agent 또는 Codex를 활용해 구현할 경우, 사람이 직접 검증하기 전까지 변경 안정성을 판단하기 어려움 +- PR 단위로 기능이 정상 동작하는지 자동 확인할 수 있는 기준이 없음 +### 3. 목표 (Goal) +- Playwright 기반 E2E 테스트 환경 구축 +- 서비스 핵심 사용자 흐름을 기준으로 테스트 시나리오 선정 +- 테스트 케이스를 문서화해 자동화 우선순위 결정 +- 핵심 시나리오부터 E2E 테스트 코드 작성 +- GitHub Actions에서 E2E 테스트를 실행할 수 있도록 워크플로우 구성 +- 실패 시 HTML report 또는 trace 등 디버깅 산출물을 확인할 수 있는 구조 마련 +#### 이번 작업에서 해결하지 않는 범위 +- 모든 기능의 E2E 테스트 자동화 +- 단위 테스트, 통합 테스트 전면 도입 +- 시각적 회귀 테스트 도입 +- 성능 테스트 자동화 +- 테스트 전용 DB 또는 seed 시스템의 완전한 고도화 +- 모든 브라우저, 모든 디바이스 조합에 대한 테스트 +### 4. 구현 방향 (Implementation) +- 먼저 핵심 사용자 흐름을 기준으로 E2E 테스트 시나리오를 선정 +- 테스트 자동화 난이도와 중요도를 기준으로 우선순위 분류 +- Playwright 설정 파일, 테스트 디렉토리, 공통 fixture, 인증 상태 관리 방식을 설계 +- 소셜 로그인 버튼 클릭 이후의 실제 Provider 인증 화면은 우리 코드가 아니라 Google·Kakao가 렌더링하므로 자동화 대상에서 제외하고, 대신 Supabase Admin API로 테스트 유저와 세션을 직접 생성해 브라우저에 주입하는 세션 주입 방식을 채택 +- 세션 주입으로 만든 로그인 상태는 그룹·초대·정산·채팅 등 로그인 이후 기능 테스트 전반에서 재사용 +- 실제 검증 대상은 로그인 콜백 이후 로직인 세션 확인, 유저 조회, 약관 동의 체크, 리다이렉트 분기로 한정 +- 신규 가입과 회원탈퇴는 Supabase Admin API로 테스트 유저를 생성하고 삭제하는 방식으로 매 실행마다 독립적으로 재현 +- 실제 Provider 연동 자체의 오류는 세션 주입으로 잡히지 않으므로, CI와 별도로 낮은 빈도의 수동 확인을 안전망으로 유지 +- 초대 기능처럼 2개 이상의 계정이 필요한 시나리오는 서로 다른 유저의 세션을 각각의 BrowserContext에 주입하는 방식으로 정의 +- 초기에는 가장 중요한 1\~2개 플로우부터 자동화하고, 이후 도메인별로 점진적으로 확장 +- GitHub Actions에서는 의존성 설치, Playwright 브라우저 설치, 테스트 실행, 리포트 업로드 순서로 구성 +### 5. 검토한 대안 (Alternatives) + + + + + + + + + + + + + + + + + + + + + + + + + +
대안장점단점선택 여부
**Playwright 기반 E2E 테스트**실제 브라우저 기반 사용자 흐름 검증 가능
로그인, 페이지 이동, 입력, 클릭, 네트워크 응답 등 실제 사용 시나리오 검증에 적합
GitHub Actions 연동과 HTML report, trace 등 디버깅 도구 활용 가능
Next.js 웹 서비스와 궁합이 좋음		테스트 작성과 유지보수 비용 발생
테스트 데이터, 인증 상태, 외부 의존성 관리가 필요
시나리오가 많아지면 실행 시간이 증가할 수 있음		**선택**
**수동 테스트 체크리스트만 유지**도입 비용이 낮음
복잡한 설정 없이 바로 테스트 가능
초기 기획 단계에서는 빠르게 확인 가능		반복 비용이 크고 누락 가능성이 높음
PR 또는 배포 전 자동 검증이 불가능
AI Agent가 구현한 변경사항의 안정성을 자동으로 판단하기 어려움		**미선택**
**단위 테스트 우선 도입**개별 함수나 컴포넌트 로직 검증에 유리
빠르게 실행 가능
디버깅 범위가 작음		실제 사용자 흐름 전체를 검증하기 어려움
초대, 로그인, 페이지 이동, DB 반영 등 복합 시나리오 검증에는 한계가 있음		**이번 작업에서는 미선택**
+#### 최종 선택 +- Playwright 기반 E2E 테스트를 선택 +- 이번 작업의 핵심 목적은 단순 함수 검증이 아니라 사용자가 실제로 기능을 정상적으로 사용할 수 있는지 확인하는 것 +- 수동 테스트 체크리스트는 자동화를 위한 테스트 케이스 문서화에 사용하고, 최종적으로는 핵심 플로우를 Playwright 테스트로 전환 +### 6. 영향 범위 (Impact) +#### 기능 영향 범위 +- 로그인 및 인증 흐름 +- 그룹 생성 흐름 +- 초대 생성 및 초대 수락 흐름 +- 정산 상태 확인 또는 변경 흐름 +- 핵심 페이지 진입 및 주요 CTA 동작 +#### 코드 영향 범위 +- Playwright 설정 파일 +- E2E 테스트 디렉토리 +- GitHub Actions workflow 파일 +- Supabase Admin API 기반 세션 주입 helper 및 service role key 관리 구조 +- 테스트 환경 변수 및 GitHub Actions Secrets +- 세션을 생성하고 주입하는 인증 setup 프로젝트 +- 테스트에서 재사용할 fixture, helper, page object +- 가입·탈퇴 테스트 전후 엔빵 내부 사용자 상태를 보장하는 cleanup 유틸 +- 필요 시 테스트용 seed 또는 추가 데이터 정리 유틸 +- 실제 Provider 연동 확인을 위한 낮은 빈도 수동 점검 절차 문서 +#### 회귀 테스트 필요 영역 +- 로그인 후 주요 페이지 접근 가능 여부 +- 그룹 생성 후 생성 결과 확인 +- 초대 링크 또는 친구 초대 후 초대 수락 흐름 +- 권한이 없는 사용자의 접근 제한 +- 테스트 실행 후 데이터가 다음 테스트에 영향을 주지 않는지 확인 +### 7. Task 분해 (Task Breakdown) +#### 1. 테스트 시나리오 선정 +- 담당: ChatGPT +- 성격: 문서 작업 +- 작업 내용 + - 핵심 사용자 흐름 목록화 + - 중요도와 자동화 난이도 기준으로 우선순위 분류 + - 1차 자동화 대상 시나리오 선정 +- 완료 조건 + - 자동화 우선순위가 포함된 테스트 시나리오 목록 작성 +#### 2. 테스트 케이스 문서화 +- 담당: ChatGPT +- 성격: 문서 작업 +- 작업 내용 + - 시나리오별 Given / When / Then 정리 + - 필요한 계정, 선행 데이터, 기대 결과 작성 + - 성공 케이스와 실패 케이스 분리 +- 완료 조건 + - Codex가 테스트 코드 작성에 참고할 수 있는 테스트 케이스 문서 작성 +#### 3. Playwright 도입 범위 및 워크플로우 설계 +- 담당: ChatGPT +- 성격: 문서 작업 +- 작업 내용 + - 테스트 디렉토리 구조 설계 + - fixture, helper, page object 도입 여부 결정 + - 인증 상태 재사용 방식 검토 + - Playwright MCP 활용 범위 확인 +- 완료 조건 + - 테스트 코드 작성 전 구조와 운영 방식 정리 + - Playwright MCP 사용 여부 또는 사용 범위가 결정됨 +#### 4. Playwright 기본 설정 추가 +- 담당: Codex +- 성격: 코드 변경 +- 작업 내용 + - Playwright 패키지 및 설정 파일 추가 + - 테스트 디렉토리 구성 + - baseURL, reporter, trace, screenshot, video 설정 검토 + - 로컬 테스트 실행 스크립트 추가 +- 완료 조건 + - 로컬에서 기본 Playwright 테스트 실행 가능 +#### 5. 인증 및 테스트 데이터 준비 구조 작성 +- 담당: Codex +- 성격: 코드 변경 +- 작업 내용 + - Supabase Admin API로 테스트 유저를 생성하고 세션을 발급하는 세션 주입 helper 작성 + - 발급받은 세션을 Playwright storageState 또는 addInitScript, addCookies로 브라우저에 주입하는 구조 구현 + - service role key는 Node.js 테스트 helper에서만 사용하고 브라우저 코드에는 노출되지 않도록 보호 + - 신규 가입·회원탈퇴 시나리오는 Admin API로 매 실행마다 새 테스트 유저를 생성하고 삭제하는 방식으로 구현 + - 테스트가 중간에 실패한 경우에도 Supabase Auth 사용자 및 관련 서비스 데이터를 정리할 수 있는 cleanup helper 작성 + - 초대·채팅 등 2인 시나리오를 위해 서로 다른 유저의 세션을 각각의 BrowserContext에 주입하는 방식 정의 + - feat→dev CI에서는 핵심 시나리오 위주로 빠르게, dev→main CI에서는 전체 회귀 범위로 넓혀 실행하도록 워크플로우 범위를 구분 + - 실제 Provider 연동 오류를 잡기 위한 낮은 빈도 수동 확인 절차를 별도로 문서화 +- 완료 조건 + - 세션 주입만으로 로그인 이후 테스트인 그룹, 초대, 정산, 채팅 등을 반복 실행할 수 있음 + - 신규 가입과 회원탈퇴 시나리오를 실제 Google, Kakao 로그인 없이 Admin API 기반으로 매 실행마다 독립적으로 검증할 수 있음 + - 테스트 실패 후에도 다음 실행에 영향을 주는 사용자 및 관련 데이터가 남지 않음 + - feat→dev와 dev→main 각각의 CI 실행 범위가 문서에 명시되어 있음 +#### 6. 핵심 E2E 테스트 코드 작성 +- 담당: Codex +- 성격: 코드 변경 +- 작업 내용 + - 1차 자동화 대상 테스트 작성 + - 그룹 생성, 초대, 정산 등 핵심 플로우 자동화 + - 필요한 helper 또는 page object 정리 +- 완료 조건 + - 선정된 핵심 시나리오 테스트가 로컬에서 통과 +#### 7. GitHub Actions E2E 테스트 워크플로우 추가 +- 담당: Codex +- 성격: 코드 변경 +- 작업 내용 + - GitHub Actions workflow 작성 + - 의존성 설치, Playwright 브라우저 설치, 테스트 실행 단계 구성 + - HTML report artifact 업로드 설정 + - 실행 트리거 범위 결정 +- 완료 조건 + - PR 또는 지정된 브랜치에서 E2E 테스트 workflow 실행 가능 +#### 8. 테스트 실행 및 안정화 +- 담당: Codex +- 성격: 코드 변경 +- 작업 내용 + - 로컬 및 CI 환경에서 테스트 실행 + - 실패 원인 분석 및 flaky 가능성 조정 + - 타임아웃, selector, 테스트 데이터 충돌 문제 수정 +- 완료 조건 + - 핵심 E2E 테스트가 로컬과 CI에서 안정적으로 통과 +### 8. Phase 및 의존성 (Phase & Dependency) +#### Phase 1. 테스트 범위 정의 +- 포함 Task: 1, 2 +- 목표: 자동화할 시나리오와 테스트 케이스 확정 +- 의존성: 없음 +- 산출물: 테스트 시나리오 목록, 테스트 케이스 문서 +#### Phase 2. 테스트 구조 설계 +- 포함 Task: 3 +- 목표: Playwright 도입 방식과 테스트 운영 구조 결정 +- 의존성: Phase 1 완료 필요 +- 산출물: 테스트 디렉토리 구조, fixture/helper 전략, 인증 상태 관리 방식 +#### Phase 3. Playwright 환경 구축 +- 포함 Task: 4, 5 +- 목표: 로컬에서 E2E 테스트를 작성하고 실행할 수 있는 기반 구축 +- 의존성: Phase 2 완료 필요 +- 예상 PR 범위: Playwright 설정, 테스트 스크립트, 인증/데이터 준비 구조 +#### Phase 4. 핵심 시나리오 자동화 +- 포함 Task: 6 +- 목표: 우선순위가 높은 핵심 사용자 흐름 자동화 +- 의존성: Phase 3 완료 필요 +- 예상 PR 범위: 주요 E2E 테스트 코드, helper/page object 정리 +#### Phase 5. CI 자동화 및 안정화 +- 포함 Task: 7, 8 +- 목표: GitHub Actions에서 E2E 테스트를 실행하고 실패 시 리포트를 확인할 수 있는 구조 구축 +- 의존성: Phase 4 완료 필요 +- 예상 PR 범위: GitHub Actions workflow, CI 테스트 안정화 +### 9. GitHub Issue 생성 계획 +현재 이 설계서는 GitHub Issue #172를 구체화하기 위한 문서입니다. +#### GitHub Issue 생성 기준 +- 문서 작업은 Notion 설계서와 테스트 케이스 문서에서 관리 +- 직접적으로 코드를 변경하는 작업은 GitHub Issue 또는 Subtask로 분리 가능 +- 기존 #172가 이미 존재하므로, 이번 설계서 기준으로 #172의 제목을 수정하고 이후 작업을 추가 이슈로 분리 +#### Notion에서 우선 관리할 작업 +- + 1. 테스트 시나리오 선정 +- + 1. 테스트 케이스 문서화 +- + 1. Playwright 도입 범위 및 워크플로우 설계 +#### GitHub Issue 또는 Subtask로 분리할 수 있는 작업 +#### Issue 1. `[cicd-64/e2e] Playwright 기본 설정 추가` +- 연결 Task: 4. Playwright 기본 설정 추가 +- 비고: 기존 GitHub Issue #172 제목 수정 예정 +- 주요 작업 + - Playwright 설치 및 설정 파일 추가 + - 테스트 디렉토리 구성 + - 로컬 실행 스크립트 추가 +- 완료 조건 + - 로컬에서 기본 E2E 테스트 실행 가능 +#### Issue 2. `[test-67/e2e] 인증 및 테스트 데이터 준비 구조 작성` +- 연결 Task: 5. 인증 및 테스트 데이터 준비 구조 작성 +- 주요 작업 + - Supabase Admin API 기반 세션 주입 helper 구현 + - 테스트 데이터 생성/정리 방식 구현 +- 완료 조건 + - 세션 주입만으로 인증이 필요한 테스트 실행 가능 +#### Issue 3. `[test-68/e2e] 핵심 사용자 플로우 E2E 테스트 작성` +- 연결 Task: 6. 핵심 E2E 테스트 코드 작성 +- 주요 작업 + - 1차 자동화 대상 테스트 코드 작성 + - 그룹 생성, 초대, 정산 등 핵심 플로우 자동화 +- 완료 조건 + - 핵심 시나리오 테스트가 로컬에서 통과 +#### Issue 4. `[cicd-69/e2e] GitHub Actions E2E 테스트 워크플로우 추가` +- 연결 Task: 7. GitHub Actions E2E 테스트 워크플로우 추가 +- 주요 작업 + - workflow 파일 작성 + - 브라우저 설치 및 테스트 실행 단계 구성 + - report artifact 업로드 설정 +- 완료 조건 + - CI에서 E2E 테스트 실행 및 리포트 확인 가능 +#### Issue 5. `[test-70/e2e] E2E 테스트 안정화 및 회귀 수정` +- 연결 Task: 8. 테스트 실행 및 안정화 +- 주요 작업 + - flaky 테스트 원인 수정 + - selector, timeout, 데이터 충돌 문제 정리 +- 완료 조건 + - 로컬과 CI에서 핵심 테스트 안정 통과 +### 10. 완료 조건 (Definition of Done) +- E2E 테스트 시나리오와 테스트 케이스 문서화 완료 +- Playwright 도입 범위와 테스트 운영 방식 결정 +- Playwright 설정 및 로컬 실행 스크립트 추가 +- 인증이 필요한 테스트를 위한 계정/상태 관리 방식 마련 +- 핵심 사용자 플로우 E2E 테스트 작성 +- GitHub Actions에서 E2E 테스트 자동 실행 가능 +- 테스트 실패 시 report 또는 trace를 통해 원인 확인 가능 +- 주요 테스트가 로컬과 CI에서 안정적으로 통과 +### 11. 리스크 및 리뷰 포인트 +#### 리스크 +- 테스트 계정 또는 테스트 데이터가 실제 서비스 데이터와 충돌할 수 있음 +- 초대 기능처럼 계정 2개 이상이 필요한 시나리오는 자동화 난이도가 높음 +- service role key는 RLS를 우회하는 강한 권한이라 유출되거나 오남용되면 리스크가 큼 +- 세션 주입은 로그인 이후 로직만 검증하므로 redirect URI 오설정 등 실제 Provider 연동 오류는 잡지 못함 +- selector가 UI 변경에 취약하면 테스트 유지보수 비용이 커질 수 있음 +- CI 환경에서 브라우저 의존성, 환경 변수, baseURL 설정 문제로 실패할 수 있음 +#### 리뷰 포인트 +- 테스트 시나리오가 실제 핵심 사용자 흐름을 잘 대표하는지 확인 +- 테스트 데이터 생성 및 정리 방식이 안전한지 확인 +- 세션 주입 방식과 service role key 관리가 보안상 문제가 없는지 확인 +- 세션 주입으로 커버되지 않는 실제 Provider 연동 오류를 확인하는 수동 점검 절차가 마련되어 있는지 확인 +- 테스트 selector가 지나치게 UI 구조에 의존하지 않는지 확인 +- GitHub Actions에서 report artifact를 확인할 수 있는지 확인 +- CI에서 테스트가 너무 오래 걸리지 않도록 범위가 적절한지 확인 +### 12. 후속 작업 +- E2E 테스트 시나리오 추가 확장 +- React Query 도입 이후 데이터 fetching 흐름에 맞춘 테스트 보강 +- API Route 마이그레이션 이후 API 기반 플로우 테스트 보강 +- 테스트 전용 seed/cleanup 유틸 고도화 +- 테스트 계정 관리 방식 개선 +- 필요 시 시각적 회귀 테스트 또는 접근성 테스트 검토 +### 참고 자료 +- Playwright 공식 문서: Continuous Integration +- Playwright 공식 문서: Authentication +### 8. 테스트 전용 DB 환경 구성 +#### 배경 +E2E 테스트는 실제 브라우저에서 사용자 흐름을 검증하기 때문에 로그인, 그룹 생성, 초대 생성, 정산 정보 등록 등 DB 변경을 동반할 수 있다. 이때 운영 DB를 직접 사용하면 테스트 데이터가 운영 데이터에 섞이거나, 테스트 실패로 인해 운영 데이터가 오염될 위험이 있다. +따라서 Playwright E2E 테스트는 운영 Supabase 프로젝트가 아니라 테스트 전용 Supabase 프로젝트를 바라보도록 구성한다. +#### 기본 원칙 + + + + + + + + + + + + + + + + + + + + + + + + + +
원칙설명
운영 DB와 테스트 DB 분리E2E 테스트는 운영 Supabase 프로젝트에 접근하지 않는다.
테스트 DB는 migration으로 동기화운영 DB를 수동으로 복사하지 않고, `supabase/migrations` 기준으로 동일한 스키마를 유지한다.
테스트 데이터는 테스트 DB에만 생성로그인, 그룹 생성, 초대 생성, 만료 상태 조작 등은 테스트 DB에서만 수행한다.
민감한 키는 GitHub Secrets로 관리Supabase URL, anon key, service role key, 테스트 계정 정보는 코드에 커밋하지 않는다.
생성 데이터 cleanup테스트 중 생성한 그룹, 초대, 정산 데이터는 테스트 종료 후 정리한다.
+#### 테스트 DB 구성 방식 +테스트 전용 Supabase 프로젝트를 별도로 생성한다. +```plain text +andbread-prod // 운영 Supabase 프로젝트 +andbread-test // E2E 테스트 전용 Supabase 프로젝트 +``` +DB 구조는 운영 DB를 복사해서 관리하지 않고, migration 파일을 기준으로 동기화한다. +```plain text +DB 스키마 변경 발생 +→ migration 파일 생성 +→ 로컬 DB 적용 +→ 테스트 DB 적용 +→ 운영 DB 적용 +``` +즉, 테스트 DB는 운영 DB의 복제본이 아니라 동일한 migration을 적용받는 별도 환경으로 관리한다. +#### GitHub Actions에서 테스트 DB 접근 방식 +GitHub Actions는 테스트 전용 Supabase 접속 정보를 GitHub Secrets에서 읽어온다. +예상 Secrets: +```plain text +E2E_SUPABASE_URL +E2E_SUPABASE_ANON_KEY +E2E_SUPABASE_SERVICE_ROLE_KEY +``` +소셜 로그인만 지원하는 서비스 특성상 이메일, 비밀번호 기반 테스트 계정은 별도로 두지 않고, service role key로 세션 주입에 필요한 테스트 유저를 그때그때 생성한다. +GitHub Actions 실행 시 해당 값을 환경변수로 주입한다. +```yaml +env: + NEXT_PUBLIC_SUPABASE_URL: ${{ secrets.E2E_SUPABASE_URL }} + NEXT_PUBLIC_SUPABASE_ANON_KEY: ${{ secrets.E2E_SUPABASE_ANON_KEY }} + SUPABASE_SERVICE_ROLE_KEY: ${{ secrets.E2E_SUPABASE_SERVICE_ROLE_KEY }} + E2E_TEST_MODE: true +``` +이렇게 구성하면 CI 환경에서 실행되는 앱과 Playwright 테스트는 운영 DB가 아니라 테스트 DB만 사용한다. +#### Service Role Key 사용 주의사항 +`SUPABASE_SERVICE_ROLE_KEY`는 RLS를 우회할 수 있는 강한 권한의 키이므로 다음 원칙을 지킨다. +- 코드에 직접 작성하지 않는다. +- 브라우저 코드에서 접근하지 않는다. +- GitHub Secrets 또는 로컬 `.env.test`에서만 관리한다. +- 테스트 helper처럼 Node.js 환경에서만 사용한다. +- `E2E_TEST_MODE=true`일 때만 실행되도록 보호 장치를 둔다. +#### 테스트 데이터 준비 방식 + + + + + + + + + + + + + + + + + + + + + + + + + + +
방식사용 시점예시
세션 주입로그인이 필요한 거의 모든 테스트Admin API로 유저와 세션 생성 후 storageState 또는 쿠키로 주입
UI 조작1차 핵심 플로우로그인 후 그룹 생성, 그룹 상세 진입
API Helper2차 복잡한 상태 기반 테스트초대 링크 생성, 만료된 초대 생성, 이미 수락된 초대 생성
Seed테스트 데이터 구성이 커졌을 때여러 사용자, 그룹, 초대 상태를 한 번에 구성
+초기에는 UI로 재현 가능한 핵심 플로우부터 자동화하고, 초대 만료처럼 특정 상태가 필요한 테스트는 테스트 DB와 API Helper 구조가 준비된 이후 확장한다. +#### Task 추가 +#### 테스트 전용 Supabase 프로젝트 구성 +- 담당: 사용자 또는 Codex 보조 +- 성격: 환경 구성 +- 작업 내용 + - 테스트 전용 Supabase 프로젝트 생성 + - 운영 DB 스키마와 동일한 migration 적용 + - 테스트 계정 생성 + - 테스트 환경변수 정리 +- 완료 조건 + - 로컬과 CI에서 운영 DB가 아닌 테스트 DB를 바라볼 수 있음 +#### GitHub Actions Secrets 설정 +- 담당: 사용자 +- 성격: 환경 설정 +- 작업 내용 + - E2E 테스트용 Supabase URL, anon key, service role key 등록 + - 테스트 계정 이메일/비밀번호 등록 + - 운영 DB 관련 Secret과 혼동되지 않도록 이름 분리 +- 완료 조건 + - GitHub Actions에서 테스트용 Supabase 프로젝트에 접근 가능 +#### 테스트 데이터 helper 및 cleanup 구조 작성 +- 담당: Codex +- 성격: 코드 변경 +- 작업 내용 + - 테스트 데이터 생성 helper 작성 + - 테스트 중 생성한 데이터 cleanup helper 작성 + - helper가 테스트 환경에서만 실행되도록 보호 조건 추가 +- 완료 조건 + - E2E 테스트 실행 후 테스트 데이터가 다음 테스트에 영향을 주지 않음 \ No newline at end of file diff --git a/llm-wiki/raw/2026-08-28-e2e-tc-guide-review.md b/llm-wiki/raw/2026-08-28-e2e-tc-guide-review.md new file mode 100644 index 0000000..2296e49 --- /dev/null +++ b/llm-wiki/raw/2026-08-28-e2e-tc-guide-review.md @@ -0,0 +1,237 @@ +# E2E 테스트 케이스 관리 문서 평가와 개선안 + +## 개요 + +- 대상 문서: Notion `E2E 테스트 케이스 관리` (`392e7e8fdd1280b1b1bef4d278f61269`) + - 하위 문서: `Test Guide` (`392e7e8fdd128163ac25f233e22706c8`) + - 하위 DB: `테스트 시나리오` (`collection://392e7e8f-dd12-808e-9812-000b1eee3356`) +- 참고 문서: `E2E 테스트 도입 구현 설계 v2 (세션 주입 기반 인증 전략)` (`3b2e7e8fdd12819c9efdfdec8769d5f4`) +- 참고 원본: `raw/2026-08-14-e2e-test-case-ci-property-removal.md`, `raw/2026-08-14-e2e-tc-domain-drafting-and-runaway-push.md` +- 확인 날짜: 2026-08-28 +- 확인 방법: `ntn pages get`으로 문서 본문을 받고, `ntn datasources query`로 DB row 136건을 전부 받아 속성값 분포를 집계했다. +- 자료 성격: 사용자 요청에 따른 문서 평가 세션 기록 + +## DB 실측 집계 (136 row 기준) + +| 속성 | 분포 | +|---|---| +| 도메인 | 인증 18, 초대 15, 랜딩페이지 15, 그룹 15, 친구 14, 채팅 14, 알림 14, 커뮤니티 12, 정산 12, 마이페이지 6, 공백 1 | +| 우선순위 | P1 80, P0 43, P2 12, 공백 1, P3 0 | +| 케이스 유형 | 성공 44, 회귀 28, 예외 21, 실패 18, 권한 16, Smoke 9 | +| 테스트 레벨 | 공백 74, E2E 51, API Integration 11 | +| 계정 조건 | 로그인 1계정 79, 비로그인 27, 로그인 2계정 18, 관리자/그룹장 6, 권한 없음 4, 공백 2 | +| 데이터 준비 방식 | Seed 54, 세션 주입 25, Mock 23, 불필요 18, API Helper 13, UI 조작 3 | +| Cleanup | 필요 76, 불필요 57, 확인 필요 3 | +| 자동화 상태 | 136건 전부 공백 | +| 관련 Issue | 136건 전부 공백 | +| Spec 경로 | 136건 전부 공백 | +| 고유 시나리오 수 | 129 | +| Case ID 세그먼트 수 | 3세그먼트 111, 4세그먼트 23, 5세그먼트 1, 2세그먼트 1 | + +## 잘 되어 있는 부분 + +- 도메인, 시나리오, 테스트 케이스라는 3단 용어를 Playwright의 spec 파일, `test.describe()`, `test()`에 각각 대응시켜 문서와 코드 구조를 일치시켰다. +- DB row 1개가 `test()` 1개에 대응한다는 원칙이 명확해서 케이스 분해 기준이 흔들리지 않는다. +- 세션 주입 전략을 채택한 근거와, 그 전략으로는 redirect URI 오설정을 잡지 못한다는 트레이드오프가 함께 기록되어 있다. +- CI 대상을 속성으로 선별하지 않고 구현된 테스트 전량으로 정한 결정이 단순하고, 제외를 코드 레벨(`test.skip`, `test.fixme`)로 넘긴 것도 적절하다. +- `자동화 상태`와 `Spec 경로` 속성으로 문서와 코드를 역추적할 고리를 미리 만들어 두었다. + +## 발견한 문제 + +### P0-1. 시나리오 축이 실질적으로 동작하지 않는다 + +136개 row에 고유 시나리오가 129개다. 그룹 15개 케이스에 시나리오 15개, 랜딩페이지 15/15, 초대 15/15, 마이페이지 6/6으로 사실상 1케이스 1시나리오다. 이 상태로 코드를 만들면 `test.describe()` 안에 `test()`가 1개만 들어간다. 인증 도메인만 시나리오 12개에 케이스 18개로 정상 동작한다. + +원인은 문서에 시나리오가 "자연어 흐름"이라는 설명만 있고 여러 케이스를 묶는 판정 기준이 없기 때문이다. 그 결과 작성자가 케이스 제목을 명사로 바꿔 시나리오 칸에 넣었다. + +### P0-2. Case ID 규칙이 형식과 번호 양쪽에서 깨져 있다 + +- 형식은 `도메인-시나리오-번호` 3세그먼트로 정의했으나 실제로는 24건이 4세그먼트 이상이다. 예: `SETTLE-TOGGLE-BY-ADMIN-001`, `AUTH-LOGIN-REDIRECT-001`, `SETTLE-NOTIFICATION-PREFERENCE-001`. +- 번호가 시나리오 단위가 아니라 접두어 단위 연번이다. `GROUP-CREATE-001`부터 `005`까지가 서로 다른 5개 시나리오에 흩어져 있고, `AUTH-TERMS-001`, `003`, `005`도 각각 다른 시나리오다. +- 정산 도메인만 2026-08-14 리뷰 때 시나리오 단위로 재넘버링되어서 도메인마다 규칙이 다른 상태다. +- 번호가 어느 범위에서 유일해야 하는지 문서에 없어서, 기존 시나리오에 케이스를 중간 삽입하면 충돌한다. + +### P0-3. Test Guide 마지막 섹션의 본문이 깨져 있다 + +`## 실패 진단 정책` 섹션 전체가 줄바꿈 대신 리터럴 문자 `n`으로 이어 붙어 한 줄이 되어 있다. 실제 저장된 형태는 `## 실패 진단 정책n테스트 실패를 빠르게 원인 분석하고...따른다.n- CI 실패 시...`이며 사람이 읽기 어려운 상태다. 이전 세션에서 이 섹션을 CLI로 넣을 때 `\n` 이스케이프가 리터럴로 들어간 것으로 보인다. + +### P1-4. 설계서 v2와 Test Guide가 서로 다른 CI 기준을 말한다 + +- 설계서 v2: "feat→dev는 핵심 시나리오 위주로 빠르게 돌고, dev→main은 전체 회귀와 여러 화면 크기까지 넓혀서 돈다." (0장 트레이드오프, 4장 구현 방향, Task 5 작업 내용과 완료 조건) +- Test Guide: "feat→dev와 dev→main은 같은 케이스 세트를 실행한다. 다른 점은 화면 크기(뷰포트) 범위뿐이다." + +CI 기준을 단순화한 결정이 Test Guide에만 반영되고 설계서에는 반영되지 않았다. 두 문서 모두 기준 문서로 참조되므로 Codex가 어느 쪽을 따를지 알 수 없다. + +### P1-5. 속성의 필수 여부와 기본값이 정의되어 있지 않다 + +- `테스트 레벨`이 136건 중 74건(54%) 비어 있다. +- `자동화 상태`가 136건 전부 비어 있다. 기본값인 `미구현`조차 채워지지 않았다. +- `관련 Issue`와 `Spec 경로`도 전부 비어 있다. + +특히 `관련 Issue` 규칙이 "자동화 상태가 `미구현`이 아니면 필수"로 되어 있어서, `자동화 상태`가 비어 있는 현재 상태에서는 이 규칙이 아예 발동하지 않는다. 속성 표에 필수와 선택을 구분하는 열, 기본값, 빈 값 허용 여부가 없다. + +### P1-6. `케이스 유형` 속성에 서로 다른 분류 축이 섞여 있다 + +성공, 실패, 예외, 권한은 "무엇을 검증하는가"에 대한 값이지만, 회귀는 "왜 이 케이스를 만들었는가"라는 이력이고 Smoke는 "언제 실행하는가"라는 실행 묶음이다. 성격이 다른 세 축이 단일 select 하나에 들어가 있다. + +그 결과 회귀로 분류된 28건(21%)의 `관련 Issue`가 전부 비어 있어서, "버그가 발생하면 재현하는 회귀 케이스를 추가한다"는 운영 규칙과 맞지 않는다. 2026-08-14 리뷰에서도 회귀에서 성공으로 재분류한 건이 6건 있었다. 또한 `권한` 유형 16건과 계정 조건 `권한 없음` 4건이 서로 맞지 않는다. + +### P1-7. 스키마와 문서가 어긋나 있다 + +- `Cleanup` 속성에 문서에 없는 값 `확인 필요`가 3건 들어가 있다. +- `도메인`이 여전히 single-select다. 이전 결정인 "시나리오 축 + 도메인 다중 태그"([[e2e-tc-scenario-axis]])는 log.md에 세 번 연속 확인 필요로 남아 있다. +- P3는 문서에 정의만 있고 실제 사용이 0건이다. + +### P2-8. 우선순위로 케이스를 구분할 수 없다 + +P0 43건과 P1 80건을 합치면 123건으로 전체의 90%다. "깨지면 서비스 핵심 흐름이 막힌다"는 정성 기준만 있어서 작성자가 대부분을 상위로 올렸다. 게다가 CI가 구현된 테스트를 전량 실행하므로 우선순위는 실행 범위 결정에 쓰이지 않는다. 실제 용도인 구현 착수 순서가 문서에 적혀 있지 않아서 사실상 쓰이지 않는 속성이 되었다. + +### P2-9. `TEMPLATE-000`이 DB row로 들어가 있다 + +`도메인`이 비어 있고, 도메인 값이어야 할 `공통`이 `시나리오` 칸에 들어가 있다. 템플릿 row가 실제 케이스와 같은 DB에 있으면 집계, 필터, CI 대상 산정에 계속 섞여 들어간다. + +### P2-10. Codex 작업 경계에 금지 사항이 없다 + +"Codex가 참고할 때의 기준"은 참고 순서 6단계만 정의하고, 무엇을 하면 안 되는지는 정의하지 않는다. 2026-08-14에 검토 목적으로 위임한 fork가 스스로 하위 subagent를 만들어 8개 도메인의 케이스를 승인 없이 Notion에 push한 사고가 정확히 이 공백에서 발생했다. + +## 개선안 + +### 문서 수정으로 해결되는 항목 + +1. `실패 진단 정책` 섹션을 정상 줄바꿈으로 다시 입력한다. 앞으로 CLI로 본문을 넣을 때는 `--content`에 이스케이프 문자열을 넘기지 않고 파일을 표준 입력으로 넘긴다. +2. 시나리오 판정 기준을 추가한다. 시나리오는 같은 진입점과 같은 사전 조건을 공유하는 케이스들의 묶음으로 정의하고, 케이스가 1개뿐이면 시나리오로 승격하지 않으며, 도메인당 시나리오 3~6개와 시나리오당 케이스 2~5개를 목표로 삼는다. +3. Case ID 규칙을 확정한다. 정확히 3세그먼트를 유지하고, 시나리오 코드는 영문 대문자 단어 1개로 제한하며, 번호는 시나리오 단위로 001부터 매긴다. 도메인 코드 목록을 문서에 고정한다. +4. 속성 표에 필수 여부와 기본값 열을 추가한다. `자동화 상태`의 기본값을 `미구현`으로, `Cleanup`의 기본값을 `불필요`로 명시한다. +5. `케이스 유형`을 검증 성격(성공, 실패, 예외, 권한)만 남기고, 회귀와 Smoke는 다중 선택 `태그` 속성으로 분리한다. 회귀 태그가 붙으면 `관련 Issue`를 필수로 한다. +6. 우선순위의 용도를 "미구현 케이스의 구현 착수 순서"로 명시하고 도메인당 P0 최대 3개라는 상한을 둔다. +7. Codex와 에이전트의 작업 경계 절을 신설한다. 초안은 저장소의 `llm-wiki/output/`에만 작성하고, Notion DB 반영은 사람이 하며, 검토 목적으로 위임된 에이전트는 하위 에이전트를 생성하지 않는다. + +### DB 데이터 작업이 필요한 항목 + +8. `Cleanup`의 `확인 필요` 3건을 필요 또는 불필요로 정리한다. +9. `TEMPLATE-000` row를 DB 밖의 일반 페이지로 옮긴다. +10. `도메인` 속성의 single-select 유지 여부를 결정한다. 현재 규칙이 "도메인이 spec 파일을 결정한다"이므로 다중 태그로 바꾸면 하나의 row가 어느 spec에 들어갈지 모호해진다. 다중 태그가 필요하면 `도메인`(단일, spec 결정용)과 `관련 영역`(다중, 필터용)을 분리하는 방식을 권장한다. +11. 24건의 Case ID를 3세그먼트 규칙에 맞게 재부여하고, 번호를 시나리오 단위로 재정렬한다. +12. 129개 시나리오를 새 판정 기준에 맞게 재정리한다. 그룹 도메인의 경우 15개 시나리오가 CREATE, HOME, DETAIL, CALENDAR, DELETE, PERMISSION 6개 정도로 수렴한다. +13. `테스트 레벨` 공백 74건과 `자동화 상태` 공백 136건을 채운다. + +### 다른 문서 수정이 필요한 항목 + +14. 설계서 v2의 0장, 4장, Task 5에 남아 있는 "feat→dev 핵심 위주, dev→main 전체 회귀" 서술을 "동일 케이스 세트, 뷰포트 matrix만 상이"로 정정한다. + +## 이번 세션의 처리 범위 + +사용자는 위 개선안 중 문서 수정 항목을 Notion에 직접 반영할 것을 요청했고, 10번 도메인 축 결정은 수정 이후 다시 논의하기로 했다. + +## 확인 필요 + +- DB 데이터 작업 항목(8, 9, 11, 12, 13)은 136개 row의 값을 바꾸는 작업이라 문서 수정과 분리해서 진행할 필요가 있다. +- 11번과 12번은 서로 의존한다. 시나리오를 먼저 재정리해야 Case ID의 시나리오 세그먼트와 번호를 확정할 수 있다. + +## 반영 작업 중 추가로 발견한 문제 + +Notion 데이터 소스 스키마를 직접 조회한 결과, Test Guide가 쓰던 속성 이름과 실제 DB 속성 이름이 4건 달랐다. `ntn datasources query` 출력에는 헤더가 없어서 처음 평가할 때는 드러나지 않았다. + +| Test Guide 표기 | 실제 DB 속성 이름 | +|---|---| +| 이름 | 테스트 케이스 (title) | +| Case ID | ID | +| 계정 조건 | 계정 | +| Cleanup | 클린업 | + +Codex가 문서에 적힌 이름으로 속성을 찾으면 4개가 전부 실패하므로, 문서 쪽을 실제 속성 이름에 맞추는 방향으로 수정했다. 반대로 DB 속성 이름을 더 설명적인 쪽(`ID` → `Case ID`, `계정` → `계정 조건`)으로 바꾸는 선택지도 있으나, 스키마 변경은 이번 요청 범위 밖이라 하지 않았다. + +또한 `도메인` select에 세션 주입 전환으로 폐기된 `❌ 소셜 로그인` 옵션이 남아 있는 것을 확인했다. 옵션 삭제는 하지 않고, 문서에 새 row에 쓰지 않는다는 안내만 추가했다. + +## 이번 세션에서 실제로 반영한 내용 + +### 테스트 시나리오 DB (`collection://392e7e8f-dd12-808e-9812-000b1eee3356`) + +- `태그` multi-select 속성을 추가했다. 옵션은 회귀(orange)와 Smoke(blue)다. 기존 row의 값은 건드리지 않았으므로 현재 전부 비어 있다. + +### Test Guide (`392e7e8fdd128163ac25f233e22706c8`) + +- 2026-08-28 개정 사실을 알리는 콜아웃을 추가했다. +- `시나리오 판정 기준` 절을 신설했다. 같은 진입점과 사전 조건을 공유하는 케이스의 묶음이라는 정의, 케이스 1개짜리 시나리오 금지, 도메인당 시나리오 3~6개와 시나리오당 케이스 2~5개라는 목표 범위, 좋은 예와 좋지 않은 예 표를 담았다. +- `ID 작성 규칙` 절을 신설했다. 3세그먼트 고정, 시나리오코드는 영문 대문자 단어 1개, 번호는 시나리오 단위 001부터라는 규칙과 도메인코드-spec 파일 대응표를 담았다. +- `용어 정의` 표의 시나리오 설명을 새 정의로 바꿨다. +- `DB 속성 작성 기준` 표에 `필수 여부`와 `기본값` 열을 추가하고, 속성 이름을 실제 스키마 이름으로 맞췄다. `태그` 행을 추가했다. `자동화 상태`가 비면 관련 Issue와 Spec 경로의 필수 조건이 발동하지 않는다는 경고를 넣었다. +- `케이스 유형`의 설명을 검증 성격(성공, 실패, 예외, 권한)으로 한정하고, 회귀와 Smoke는 `태그`로 옮겼으며 기존 row 정리 전까지 남아 있을 수 있다고 명시했다. +- `우선순위 기준`에 우선순위가 CI 실행 범위가 아니라 구현 착수 순서를 정하는 값이라는 설명과 도메인당 P0 최대 3개라는 상한을 추가했다. +- `Codex와 에이전트 작업 경계` 절을 신설했다. 초안은 `llm-wiki/output/`에만, Notion 반영은 사람이, 검토 위임 에이전트는 하위 에이전트를 만들지 않는다는 세 가지 경계와 그 계기가 된 2026-08-14 사고를 적었다. +- `운영 규칙`에 회귀 케이스는 `태그`와 `관련 Issue`를 함께 채운다는 항목과, 문서와 DB 스키마를 같은 작업에서 함께 바꾼다는 항목을 추가했다. +- 테스트 케이스 제목을 평서문으로 쓰고 해요체를 쓰지 않는다는 문장을 추가했다. +- 줄바꿈이 리터럴 `n`으로 깨져 있던 `실패 진단 정책` 절을 정상 형태로 다시 넣었다. + +### E2E 테스트 도입 구현 설계 v2 (`3b2e7e8fdd12819c9efdfdec8769d5f4`) + +- 0장 트레이드오프, Task 5 작업 내용, Task 5 완료 조건에 남아 있던 "feat→dev는 핵심 시나리오 위주, dev→main은 전체 회귀" 서술을 "같은 케이스 세트, 뷰포트 matrix만 상이"로 정정했다. 0장에는 정정 사실과 기준 문서가 Test Guide라는 점을 괄호로 남겼다. + +### 저장소 + +- 수정 전 원본을 `raw/2026-08-28-test-guide-before-revision.md`와 `raw/2026-08-28-design-v2-before-revision.md`에 저장했다. + +## 반영 방법에 대한 메모 + +Notion 본문을 CLI로 넣을 때 `ntn pages edit --content '...'`에 이스케이프 문자열을 넘기면 `\n`이 리터럴 `n`으로 들어갈 수 있다. 이번 개정에서는 파일을 표준 입력으로 넘기는 `ntn pages edit < file.md` 방식을 썼고, 반영 후 다시 받아 원본과 비교해 표와 콜아웃이 그대로 유지되는 것을 확인했다. + +## 남은 작업 + +- `케이스 유형`의 회귀 28건과 Smoke 9건을 `태그`로 옮기고, `케이스 유형`을 검증 성격 값으로 다시 지정한다. +- `테스트 레벨` 공백 74건과 `자동화 상태` 공백 136건을 채운다. +- `클린업`의 `확인 필요` 3건을 정리하고 select 옵션에서 뺀다. +- `도메인` select에서 `❌ 소셜 로그인` 옵션을 뺀다. +- `TEMPLATE-000` row를 DB 밖으로 옮긴다. +- 129개 시나리오를 새 판정 기준으로 재정리하고, 그 결과에 맞춰 24건의 ID를 3세그먼트로 재부여한다. +- `도메인` 속성의 축 결정(단일 유지 또는 `도메인`과 `관련 영역` 분리)은 사용자와 다시 논의하기로 했다. + +## DB row 데이터 정리 (같은 날 후속 작업) + +사용자가 "남은 작업을 순차적으로 진행"하도록 요청해서, 문서 수정 이후 `테스트 시나리오` DB의 row 데이터를 실제로 정리했다. + +### 작업 방법 + +`ntn api`는 경로를 `v1/...` 형태(맨 앞 슬래시 없이)로 넘겨야 동작한다. `/v1/...`이나 `v1` 없는 형태는 전부 `invalid_request_url`을 반환한다. 또한 여러 번 연속 호출하면 ntn이 OpenAPI 스펙을 매번 받아오다가 `403 Forbidden`으로 실패하므로 `NOTION_API_VERSION=2025-09-03`을 지정해 스펙 조회를 건너뛰어야 한다. Bash에서 반복 호출 루프는 도구 정책에 막혀서 PowerShell로 실행했다. 요청 본문은 BOM이 없는 파일로 저장해 `-d @파일` 형태로 넘겼다. + +`ntn pages edit`은 본문만 교체하고 frontmatter의 속성값은 무시한다. 속성 변경은 `v1/pages/{id}` PATCH로만 가능하다. + +### 반영 내용 + +1. **`자동화 상태` 135건을 `미구현`으로 채웠다.** 전부 비어 있어서 `관련 Issue`와 `Spec 경로`의 조건부 필수 규칙이 발동하지 않던 상태를 해소했다. +2. **`테스트 레벨` 공백 73건을 채웠다.** 71건은 `E2E`, 서버사이드 알림 호출을 검증하는 `CHAT-NOTIFY-001`(당시 CHAT-NOTIFICATION-001)과 `FRIEND-NOTIFY-002`(당시 FRIEND-NOTIFICATION-002)는 같은 도메인의 다른 알림 케이스와 맞춰 `API Integration`으로 분류했다. +3. **`케이스 유형`의 회귀 28건을 재분류했다.** 28건 모두 버그 재현이 아니라 정상 동작이나 경계 조건을 검증하는 케이스였고, 연결된 GitHub Issue도 하나도 없었다. 새 기준(회귀는 버그 재현 이력이며 `관련 Issue` 필수)에 맞지 않으므로 `회귀` 태그를 붙이지 않고 검증 성격에 따라 성공 18건과 예외 10건으로 나눴다. 2026-08-14 리뷰에서 사람이 이미 같은 이유로 6건을 회귀에서 성공으로 바꾼 선례를 따랐다. +4. **`케이스 유형`의 Smoke 8건을 `태그`로 옮겼다.** `케이스 유형`은 전부 `성공`으로 바꾸고 `태그`에 `Smoke`를 넣었다. +5. **`클린업`의 `확인 필요` 3건**(GROUP-DELETE-001, AUTH-DELETE-003, COMMUNITY-DELETE-002)을 전부 `필요`로 정리했다. 세 건 모두 선행 데이터를 만들어 두고 삭제 동작을 검증하는 케이스라서 실패 시 잔여 데이터가 남을 수 있다. +6. **`TEMPLATE-000` row를 DB 밖으로 옮겼다.** 본문을 그대로 옮긴 일반 페이지 `테스트 케이스 작성 템플릿`(`3cae7e8fdd12812c823efa4f74de8325`)을 `E2E 테스트 케이스 관리` 아래에 만들고, DB row는 휴지통으로 보냈다. +7. **select 옵션을 정리했다.** `케이스 유형`에서 회귀와 Smoke를 뺐고, `클린업`에서 `확인 필요`를 뺐고, `도메인`에서 폐기된 `❌ 소셜 로그인`을 뺐다. +8. **시나리오 129개를 43개로 재정리하고 그에 맞춰 ID 117건을 다시 부여했다.** 도메인당 시나리오 3~5개, 시나리오당 케이스 2~6개가 되었다. 모든 ID가 3세그먼트가 되었고 번호는 시나리오 단위 001부터다. + +### 시나리오 재정리 결과 + +| 도메인 | 시나리오 수 | 케이스 수 | 시나리오 | +|---|---|---|---| +| 인증 | 5 | 18 | 로그인 콜백 처리(4), 복귀 경로 검증(2), 접근 제어(5), 약관 동의(4), 회원 탈퇴(3) | +| 그룹 | 5 | 15 | 그룹 생성(6), 홈 그룹 조회와 상세 진입(3), 홈 캘린더 조회(2), 그룹 삭제(2), 참여자 권한과 그룹 탈퇴(2) | +| 초대 | 5 | 15 | 초대 링크 조회(5), 초대 응답(4), 초대 응답 자격 검증(2), 초대 보내기(2), 받은 초대 목록 조회(2) | +| 정산 | 4 | 12 | 납부 상태 변경(4), 납부 상태 저장 처리(2), 정산 기간 기록 조회(2), 납부 완료 알림 발송(4) | +| 채팅 | 4 | 14 | 채팅 내역 조회(3), 메시지 표시와 실시간 수신(3), 메시지 전송(4), 채팅 알림 발송(4) | +| 커뮤니티 | 3 | 12 | 게시글 목록 조회(4), 게시글 작성(3), 게시글 수정과 삭제(5) | +| 친구 | 4 | 14 | 친구 태그 검색(5), 친구 요청 보내기(4), 친구 목록 조회(2), 친구 요청 알림 발송(3) | +| 알림 | 5 | 14 | 알림 목록 조회(3), 알림 선택 동작(4), 알림 삭제(2), 알림 설정 변경(3), 알림 권한 처리(2) | +| 랜딩페이지 | 5 | 15 | 랜딩페이지 조회(3), 로그인 시작(2), 스크롤 등장 효과(3), iOS 설치 안내 조회(3), 검색과 설치 메타데이터 제공(4) | +| 마이페이지 | 3 | 6 | 프로필 조회(2), 로그아웃(2), 마이페이지 메뉴 진입(2) | + +### 정리 후 상태 (135 row) + +- ID 중복 없음, 전부 3세그먼트 +- 케이스 유형: 성공 71, 예외 30, 실패 18, 권한 16 +- 테스트 레벨: E2E 122, API Integration 13 +- 자동화 상태: 미구현 135 +- 클린업: 필요 79, 불필요 56 +- 태그: Smoke 8, 나머지 없음 + +## 이번 정리로 해결되지 않은 것 + +- **`계정` 공백 2건**(`FRIEND-NOTIFY-001`, `FRIEND-NOTIFY-003`). 서버사이드 웹훅을 직접 호출하는 케이스라 브라우저 세션 개념이 없어서 select 값 중 맞는 것이 없다. 2026-08-14에도 사람이 같은 이유로 비워 두기로 판단했기 때문에 이번에도 강제로 채우지 않았다. Test Guide는 `계정`을 필수로 정의하고 있으므로, `해당 없음` 같은 옵션을 추가할지 결정이 필요하다. 같은 이유로 `CHAT-NOTIFY-003`, `CHAT-NOTIFY-004`에는 정확하지 않은 `비로그인`이 들어가 있다. +- **P0 43건이 도메인당 최대 3개 규칙을 넘는다.** 인증 8, 그룹 7, 초대 6, 친구 6, 정산 4, 커뮤니티 4, 채팅 3, 랜딩페이지 2, 알림 2, 마이페이지 1이다. 우선순위 재조정은 어떤 흐름이 핵심인지에 대한 판단이라 이번 정리에 넣지 않았다. +- **`도메인` 속성의 축 결정**은 사용자와 다시 논의하기로 한 상태 그대로다. diff --git a/llm-wiki/raw/2026-08-28-test-guide-before-revision.md b/llm-wiki/raw/2026-08-28-test-guide-before-revision.md new file mode 100644 index 0000000..e540094 --- /dev/null +++ b/llm-wiki/raw/2026-08-28-test-guide-before-revision.md @@ -0,0 +1,351 @@ +--- +title: Test Guide +--- + + + 인증 전략이 실제 Provider 로그인 자동화에서 세션 주입 방식으로 바뀌면서 이 문서도 함께 개정되었습니다. OAuth 실제 로그인 관련 예시와 CI 기준을 세션 주입 기준으로 수정했습니다. 배경은 문서를 참고해주세요. + +## 목적 +이 문서는 엔빵 E2E 테스트 케이스를 작성하고 관리하기 위한 기준을 정의한다. +테스트 케이스 DB는 기획자, QA, 개발자가 함께 테스트 케이스를 추가하고, Codex가 해당 내용을 참고해 Playwright 테스트 코드를 작성할 수 있도록 관리한다. +## 기본 원칙 +- DB row 1개는 Playwright의 `test()` 1개와 대응되는 것을 기본 원칙으로 한다. +- Playwright `spec` 파일은 도메인 단위로 분리한다. +- Playwright `test.describe()`는 시나리오 단위로 그룹화한다. +- 성공 케이스와 예외 케이스는 같은 문서 안에 묶지 않고 각각 별도 row로 분리한다. +- DB 표보기에는 필터링과 관리에 필요한 속성만 둔다. +- Codex가 참고해야 하는 세부 조건, Given / When / Then, 테스트 데이터, 주의사항은 각 테스트 케이스 페이지 본문에 작성한다. +## 용어 정의 + + + + + + + + + + + + + + + + + + + + + +
용어의미Playwright 대응
도메인테스트를 기능 영역별로 묶는 가장 큰 단위`auth.spec.ts`, `group.spec.ts` 등 spec 파일
시나리오도메인 안에서 사용자가 수행하는 하나의 흐름을 자연어 문장형으로 표현한 것`test.describe()`
테스트 케이스하나의 구체적인 검증 항목`test()`
+예시: +```plain text +도메인: 인증 +시나리오: 로그인 콜백 처리 +테스트 케이스: 세션이 주입된 사용자는 로그인 콜백 이후 홈 화면에 진입한다 +``` +Playwright 구조 예시: +```typescript +test.describe('로그인 콜백 처리', () => { + test('세션이 주입된 사용자는 로그인 콜백 이후 홈 화면에 진입한다', async ({ page }) => { + // ... + }); +}); +``` +소셜 로그인 버튼 클릭 이후의 실제 Provider 인증 화면은 우리 코드가 아니라 Google·Kakao가 렌더링하므로 자동화 대상에서 제외한다. Supabase Admin API로 생성한 세션을 주입한 상태에서 시작해, 로그인 콜백 이후 로직인 세션 확인, 유저 조회, 약관 동의, 리다이렉트 분기를 검증하는 것을 인증 도메인의 기본 테스트 방식으로 삼는다. +## 테스트 케이스 작성 단위 +좋은 테스트 케이스는 하나의 기대 결과를 명확하게 검증한다. + + + + + + + + + + + + + + + + + +
좋음좋지 않음
세션이 주입된 사용자는 로그인 콜백 이후 홈 화면에 진입한다로그인 관련 전체 예외 케이스를 모두 확인한다
로그인하지 않은 사용자는 보호된 화면에 접근할 수 없다인증 관련 모든 접근 제한을 한 번에 확인한다
로그인한 사용자는 그룹을 생성할 수 있다그룹 생성, 초대, 정산까지 한 번에 확인한다
+예외 상황이 많을 경우 예외를 본문 하위 항목으로만 나열하지 않고, 필요한 경우 독립된 테스트 케이스로 분리한다. +```plain text +AUTH-CALLBACK-001 세션이 주입된 사용자는 로그인 콜백 이후 홈 화면에 진입한다 +AUTH-CALLBACK-002 약관에 동의하지 않은 사용자는 약관 동의 화면으로 이동한다 +AUTH-CALLBACK-003 신규 가입 사용자는 서비스 사용자 생성 흐름을 거친다 +AUTH-ACCESS-001 로그인하지 않은 사용자는 보호된 화면에 접근할 수 없다 +``` +## DB 속성 작성 기준 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
속성작성 기준
이름테스트 케이스 제목을 작성한다. 예: 로그인하지 않은 사용자는 보호된 화면에 접근할 수 없다
Case ID도메인, 시나리오, 번호를 조합한다. 예: AUTH-KAKAO-001, AUTH-ACCESS-001, GROUP-CREATE-001
도메인인증, 랜딩페이지, 그룹, 초대, 정산, 채팅, 커뮤니티, 친구, 알림, 마이페이지, 공통 중 선택한다.
시나리오도메인 안에서 사용자가 수행하는 하나의 흐름을 자연어 문장형으로 작성한다. 예: 카카오 로그인, 접근 제어, 그룹 생성
케이스 유형성공, 실패, 예외, 권한, 회귀, Smoke 중 선택한다.
우선순위P0은 절대 깨지면 안 되는 핵심 흐름, P1은 중요 기능, P2는 확장 대상, P3는 낮은 우선순위로 둔다.
데이터 준비 방식세션 주입, UI 조작, API Helper, Seed, Mock, 수동, 불필요 중 선택한다.
계정 조건비로그인, 로그인 1계정, 로그인 2계정, 관리자/그룹장, 권한 없음 중 선택한다.
Cleanup테스트 후 생성 데이터 정리가 필요한지 선택한다.
관련 Issue관련 GitHub Issue URL을 입력한다. 자동화 상태가 `미구현`이 아니면 필수로 입력한다.
테스트 레벨E2E, API Integration, 수동 중 선택한다. Playwright API request로 Edge Function/웹훅 엔드포인트를 직접 호출해 응답이나 DB 행을 검증하는 케이스는 API Integration으로 분류한다. 브라우저 화면 조작과 렌더링 결과를 검증하는 케이스는 E2E로 분류한다.
자동화 상태미구현, 구현, 제외 중 선택한다. Playwright 코드로 아직 옮기지 않았으면 미구현, 구현했으면 구현, 자동화 대상이 아니면 제외로 표시한다.
Spec 경로자동화 상태가 `구현`이면 해당 test()가 위치한 spec 파일 경로를 입력한다. 예: `e2e/friend.spec.ts`
+## 우선순위 기준 + + + + + + + + + + + + + + + + + + + + + + + + + + +
우선순위기준예시
P0깨지면 서비스 핵심 흐름이 막히는 케이스보호 화면 접근 제어, 그룹 생성, 그룹 상세 진입
P1중요 기능이지만 P0보다 우선순위가 낮은 케이스세션 주입 후 홈 진입, 초대 링크 생성, 초대 수락
P2예외 상황 또는 확장 자동화 대상만료된 링크, 이미 참여한 사용자, 로그인 취소
P3자동화 필요성이 낮거나 수동 확인이 더 적합한 케이스시각적 요소, 낮은 빈도의 부가 기능
+## CI 기준 +엔빵은 아직 기능 수가 많지 않으므로 구현된 테스트 케이스는 전부 CI 대상으로 삼는다. 별도 속성으로 케이스를 선별하지 않는다. +- 구현된 모든 테스트는 feat→dev, dev→main 두 단계 모두에서 자동 실행한다. +- 실제 Provider 로그인 화면 자체는 CI에서 자동화하지 않는다. 로그인이 필요한 케이스는 Supabase Admin API 기반 세션 주입으로 인증 상태를 만들고, 그 이후 로직만 검증한다. +- redirect URI 오설정처럼 세션 주입으로 잡히지 않는 실제 Provider 연동 오류는 CI 대상이 아니며, 별도의 낮은 빈도 수동 점검으로 확인한다. +- feat→dev와 dev→main은 같은 케이스 세트를 실행한다. 다른 점은 화면 크기(뷰포트) 범위뿐이며, 이는 GitHub Actions 워크플로우의 matrix 설정으로 다룬다. Notion 문서나 스키마를 바꿀 필요는 없다. +- 특정 케이스를 일시적으로 제외해야 하면 Notion 속성이 아니라 코드 레벨에서 Playwright의 `test.skip()` 또는 `test.fixme()`로 처리한다. +- CI에 포함된 테스트가 실패하면 merge를 막는 기준으로 사용한다. +## 데이터 준비 방식 기준 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
방식설명사용 예시
세션 주입Supabase Admin API로 테스트 유저와 세션을 생성해 브라우저에 주입한다. 로그인이 필요한 대부분의 테스트에서 기본으로 사용한다.로그인 콜백 이후 홈 진입, 그룹·초대·정산 등 로그인 이후 기능 테스트
UI 조작Playwright가 실제 화면을 조작해 데이터를 만든다.세션 주입 이후 그룹 생성
API Helper테스트 helper가 API 호출 또는 테스트 DB 조작으로 필요한 상태를 만든다.만료된 초대 링크 생성
Seed테스트 시작 전에 여러 데이터를 한 번에 구성한다.사용자 2명, 그룹, 초대 상태 일괄 생성
Mock외부 의존성을 가짜 응답으로 대체한다.알림, 외부 API
수동자동화 전 사람이 직접 확인한다.초기 탐색 테스트, 실제 Provider 로그인 연동의 낮은 빈도 점검
불필요별도 데이터 준비 없이 실행 가능하다.비로그인 접근 제한
+## 테스트 DB 사용 기준 +E2E 테스트는 운영 DB가 아니라 테스트 전용 Supabase 프로젝트를 사용한다. +- 운영 DB와 테스트 DB는 분리한다. +- 테스트 DB 구조는 migration으로 운영 DB와 동기화한다. +- GitHub Actions에서는 GitHub Secrets로 테스트 DB 접속 정보를 주입한다. +- 테스트 중 생성한 데이터는 cleanup 대상 여부를 명시한다. +- service role key는 브라우저 코드에 노출하지 않고 Node.js 테스트 helper에서만 사용한다. +## 상세 페이지 작성 템플릿 +각 테스트 케이스 페이지 본문에는 아래 형식을 사용한다. +```markdown +## 목적 +이 테스트가 필요한 이유를 작성한다. + +## 시나리오 +사용자 관점에서 어떤 흐름을 검증하는지 한 문단으로 작성한다. + +## Given +- 테스트 시작 전 상태를 작성한다. + +## When +- 사용자의 행동을 순서대로 작성한다. + +## Then +- 검증해야 하는 결과를 작성한다. + +## 테스트 데이터 +- 필요한 계정, 그룹, 초대, 정산 데이터 등을 작성한다. + +## 데이터 준비 방식 상세 +- DB 속성의 데이터 준비 방식을 구체적으로 설명한다. + +## Cleanup 대상 +- 테스트 종료 후 정리해야 하는 데이터를 작성한다. + +## 예외/주의사항 +- flaky 가능성, 다중 계정 필요 여부, 외부 서비스 의존성, cleanup 주의사항을 작성한다. + +## 관련 정책 또는 참고 문서 +- 관련 구현 설계서, GitHub Issue, 기능 문서 링크를 작성한다. +``` +## 작성 예시 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
속성값
이름로그인하지 않은 사용자는 보호된 화면에 접근할 수 없다
Case IDAUTH-ACCESS-001
도메인인증
시나리오접근 제어
케이스 유형권한
우선순위P0
데이터 준비 방식불필요
계정 조건비로그인
Cleanup불필요
+```markdown +## 목적 +비로그인 사용자가 인증이 필요한 화면에 직접 접근했을 때 보호된 화면이 노출되지 않는지 확인한다. + +## 시나리오 +사용자가 로그인하지 않은 상태에서 보호된 경로에 직접 접근하면 로그인 페이지로 이동해야 한다. + +## Given +- 사용자는 로그인하지 않은 상태다. +- 보호된 경로가 존재한다. + +## When +- 사용자가 보호된 경로에 직접 접근한다. + +## Then +- 보호된 화면이 노출되지 않는다. +- 로그인 페이지로 이동한다. +- 로그인 유도 UI가 표시된다. + +## 테스트 데이터 +- 별도 테스트 데이터 불필요 +- 접근 경로 예시: 실제 보호 라우트 + +## 데이터 준비 방식 상세 +- 비로그인 상태의 새 브라우저 컨텍스트에서 테스트를 실행한다. + +## Cleanup 대상 +- 없음 + +## 예외/주의사항 +- 로그인 페이지가 보이는지만 확인하지 않고, 보호된 화면의 주요 정보가 노출되지 않는지도 함께 확인한다. +``` +## Codex가 참고할 때의 기준 +Codex는 테스트 케이스 DB에서 다음 순서로 테스트 구현 대상을 판단한다. +1. `도메인`을 기준으로 spec 파일을 선택한다. +2. `시나리오`를 기준으로 `test.describe()` 그룹을 구성한다. +3. 각 DB row를 Playwright `test()` 1개로 구현한다. +4. 본문의 Given / When / Then과 기대 결과를 기준으로 테스트를 작성한다. +5. 데이터 준비 방식과 계정 조건을 확인한다. +6. Cleanup이 필요한 경우 테스트 종료 후 데이터 정리 로직을 함께 작성한다. +## 운영 규칙 +- 새로운 기능을 개발할 때 관련 테스트 케이스를 최소 1개 이상 추가할지 검토한다. +- 버그가 발생한 경우 해당 버그를 재현하는 회귀 테스트 케이스를 추가한다. +- 구현된 테스트는 모두 PR에서 항상 통과해야 한다. +- 예외 케이스가 많은 기능은 기능 문서 하나에 몰아넣지 않고 테스트 케이스 row로 분리한다. +- 테스트 케이스가 불명확하면 본문의 Given / When / Then을 먼저 보완한다. +- Playwright 코드로 구현한 직후 해당 row의 `자동화 상태`를 `구현`으로, `Spec 경로`를 실제 파일 경로로 갱신한다. 이 값이 맞지 않으면 문서에는 있지만 코드에는 없는 테스트를 찾기 어려워진다. +## 실패 진단 정책n테스트 실패를 빠르게 원인 분석하고, flaky 테스트가 CI 신뢰도를 갉아먹지 않도록 아래 기준을 따른다.n- CI 실패 시 `playwright.config.ts`의 `trace: 'retain-on-failure'`, `screenshot: 'only-on-failure'`, `video: 'retain-on-failure'` 설정으로 trace, screenshot, video를 자동 보존한다. 별도 설정 추가는 필요 없다.n- `retries` 설정으로 재시도 후 통과한 테스트는 flaky로 간주한다. 최초 실패 원인을 기록하고, 코드 문제인지 테스트 자체의 불안정성인지 구분한다.n- 같은 테스트가 최근 CI 실행에서 반복적으로 flaky 판정되면 원인 조사 전까지 `test.fixme()`로 격리(quarantine)한다. 원인 불명 상태로 retry에만 의존해 방치하지 않는다.n- `test.skip()`은 기능이 아직 구현되지 않은 케이스에, `test.fixme()`는 구현되어 있으나 현재 실패/flaky한 케이스에 사용한다.n- quarantine된 테스트는 관련 GitHub Issue를 생성해 추적하고, 해당 테스트 케이스 페이지의 `관련 Issue`에 연결한다. \ No newline at end of file diff --git a/llm-wiki/wiki/e2e-test-case-db-classification-axis.md b/llm-wiki/wiki/e2e-test-case-db-classification-axis.md new file mode 100644 index 0000000..8e1cecc --- /dev/null +++ b/llm-wiki/wiki/e2e-test-case-db-classification-axis.md @@ -0,0 +1,33 @@ +# E2E 테스트 케이스 DB의 분류 축 결정 + +## 한 문장 요약 + +`테스트 시나리오` DB의 `도메인` 속성은 단일 select를 유지하며, 분류 축을 정교하게 다듬는 것보다 시나리오 묶음과 테스트 케이스 본문의 품질이 중요하다. + +## 근거 + +- 원천 자료: `raw/2026-08-28-e2e-tc-guide-review.md` +- 원천 자료: `raw/2026-08-14-e2e-test-case-ci-property-removal.md` +- 원천 자료: `raw/2026-08-14-e2e-tc-domain-drafting-and-runaway-push.md` +- 확인 날짜: 2026-08-28 +- 자료 성격: 문서 평가 세션 기록, 사용자 결정 +- 관련 문서: [llm-wiki 배경과 구조](llm-wiki-background-and-structure.md) + +## 확인된 내용 + +- 2026-08-05 논의에서 "시나리오 단일 축 + 도메인 다중 태그"로 전환하자는 안이 나왔으나 채택되지 않았다. 채택하지 않은 이유가 그때 기록되지 않아서, `log.md`에 2026-08-14부터 세 세션 연속으로 "도메인 속성이 아직 single-select"라는 확인 필요 항목이 남아 있었다. +- 2026-08-28에 사용자가 단일 select 유지를 확정했다. 이유는 도메인 분류보다 시나리오와 테스트 케이스 내용이 더 중요하다는 판단이다. +- 구조적으로도 `도메인`은 Playwright spec 파일을 결정하는 값이다. 다중 태그가 되면 하나의 row가 어느 spec 파일에 들어갈지 정해지지 않는다. +- 2026-08-05에 다중 태그의 근거로 들었던 문제는 도메인 간 종속 관계(엔빵과 초대, 엔빵과 게시글)에서 어느 도메인이 그 테스트 케이스를 책임지는지 모호해진다는 것이었다. 2026-08-28에 129개 시나리오를 43개로 재정리하면서 실제 데이터로 확인한 결과, 이 모호함은 시나리오를 제대로 묶으면 해소되었고 도메인 경계 때문에 배치가 곤란한 케이스는 나오지 않았다. +- `계정` 속성은 Test Guide에서 필수로 정의하지만, 브라우저 세션 개념이 없는 서버사이드 웹훅 케이스에는 맞는 select 값이 없다. 이런 케이스는 E2E가 아니라 단위 테스트로 검증하게 될 수 있으므로, 값을 강제로 채우지 않고 비워 두기로 했다. 현재 `FRIEND-NOTIFY-001`과 `FRIEND-NOTIFY-003`이 여기에 해당한다. + +## 확인 필요 + +- 다중 필터가 실제로 필요해지는 시점이 오면 `도메인`(단일, spec 결정용)과 `관련 영역`(다중, 필터용)을 분리하는 방식을 검토할 수 있다. 지금은 필요가 확인되지 않았다. +- `CHAT-NOTIFY-003`, `CHAT-NOTIFY-004`에는 서버사이드 호출인데도 `비로그인`이 들어가 있다. `계정`을 비워 두는 기준을 적용하면 이 두 건도 비우는 것이 일관적인지 확인이 필요하다. +- 우선순위 판정 기준이 확정되지 않았다. 2026-08-28에 "도메인당 P0 최대 3개" 상한은 폐지했고, 현재 P0 43건은 초안 작성 시점의 판단이 그대로 남아 있는 상태다. 실제 구현 순서를 정하는 시점에 다시 논의해 확정하기로 했다. + +## 다시 물어볼 질문 + +- 시나리오를 43개로 줄인 뒤 실제로 Playwright 코드를 작성해 보면 `test.describe()` 단위가 적절한가? +- 단위 테스트로 옮길 후보(서버사이드 웹훅 케이스)를 별도로 표시할 방법이 필요한가? 지금은 `테스트 레벨`의 `API Integration`과 구분되지 않는다. From a78c0c7ef4ead9ea7cc6bb646c865efcba97cc9b Mon Sep 17 00:00:00 2001 From: unknown Date: Tue, 1 Sep 2026 15:31:03 +0900 Subject: [PATCH 03/11] =?UTF-8?q?refactor:=20=EC=97=94=EB=B9=B5=20?= =?UTF-8?q?=EC=B9=B4=EB=93=9C=EC=99=80=20=EC=B0=B8=EC=97=AC=EC=9E=90=20?= =?UTF-8?q?=EC=B9=B4=EB=93=9C=EC=97=90=20=ED=85=8C=EC=8A=A4=ED=8A=B8?= =?UTF-8?q?=EC=9A=A9=20data-testid=20=EC=B6=94=EA=B0=80?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit E2E 테스트가 금액, 참여 인원, 납부 체크박스를 짚을 때 Tailwind 클래스와 XPath에 의존하고 있었다. 디자인을 수정하면 테스트가 함께 깨지므로 role이나 텍스트로 짚을 수 없는 지점에만 data-testid를 붙인다. - 엔빵 조회 카드의 총 금액, 참여 인원, 엔빵 금액, 정기 결제일 값 - 엔빵 생성 폼의 참여 인원, 엔빵 금액, 정기 결제일 입력 - 참여자 카드와 납부 체크박스 Checkbox는 공용 컴포넌트라 testId를 선택 prop으로 받게 한다. 값을 넘기지 않으면 data-testid 자체가 렌더되지 않아 기존 사용처의 출력은 그대로다. className과 DOM 구조는 바꾸지 않았다. Co-Authored-By: Claude Opus 5 (1M context) --- src/components/common/checkbox/checkbox.tsx | 5 +++-- src/components/nbread/nbreadCard.tsx | 20 +++++++++++++++---- src/components/nbread/nbreadEditCard.tsx | 8 +++++++- .../nbread/nbreadParticipantCard.tsx | 6 +++++- 4 files changed, 31 insertions(+), 8 deletions(-) diff --git a/src/components/common/checkbox/checkbox.tsx b/src/components/common/checkbox/checkbox.tsx index 82654d5..114b4cb 100644 --- a/src/components/common/checkbox/checkbox.tsx +++ b/src/components/common/checkbox/checkbox.tsx @@ -2,11 +2,12 @@ interface CheckboxProps { disabled?: boolean isChecked?: boolean onChange: () => void + testId?: string } -const Checkbox = ({ disabled, isChecked, onChange }: CheckboxProps) => { +const Checkbox = ({ disabled, isChecked, onChange, testId }: CheckboxProps) => { return ( -