# 테스트 및 품질 리뷰

## 실측 결과

### 실행한 검증

| 명령 | 결과 | 해석 |
|---|---|---|
| `backend/.venv/bin/python -m pytest backend/tests -q` | `637 passed, 56 failed, 2 errors, 1 skipped` | 저장소 전체는 green 아님 |
| `cd frontend && npm run build` | 성공 | 배포 번들은 생성되지만 대형 chunk 경고 존재 |
| `cd frontend && npm run lint` | `77 errors, 3 warnings` | 프런트 정적 품질 게이트 실패 |
| `rg --files frontend | rg '(test|spec)\.'` | 결과 없음 | 프런트 자동화 테스트 부재 |

### 핵심 경고

- `backend/app/core/config.py:8` Pydantic class-based `Config` deprecation
- `backend/app/main.py:45` FastAPI `on_event("startup")` deprecation
- `backend/app/api/v1/prompts.py`의 `schema_json` shadow warning
- startup 시 insecure default credentials warning 반복 출력

## 1. 백엔드 테스트 상태 해석

### 1.1 좋은 신호

- 637개 테스트가 통과한다는 점은 테스트 문화 자체가 무너진 저장소는 아니라는 뜻이다.
- 현재 리팩토링의 핵심 축인 manifest/catalog/applicability/checkpoint IO/service layer 일부는 비교적 안정적이다.
- `test_step_manifest_v3.py`, `test_step_catalog.py`, `test_applicability.py`, `tests/services/test_checkpoint_sync_services.py` 같은 현행 계약 테스트는 유효한 기준점으로 남아 있다.

### 1.2 나쁜 신호

전체 pytest는 red다. 실패는 무작위가 아니라 몇 개 묶음으로 재현된다.

#### A. startup / 환경 결합

- `backend/tests/test_pipeline_e2e.py::TestPipelineE2E::test_health_check`
- `backend/tests/test_pipeline_e2e.py::TestPipelineE2E::test_create_project`

패턴:

- app startup이 SQLite 테스트 환경에서 `user_account` 테이블을 즉시 기대한다.
- 원인 축은 `backend/app/main.py:38-45`의 import-time `init_db()`와 `@app.on_event("startup")` bootstrap이다.

#### B. legacy contract drift

- `backend/tests/test_pipeline_v3_e2e.py`
- `backend/tests/test_sync_v3.py`
- `backend/tests/test_scene_dependency_v2.py`
- `backend/tests/test_scene_director_v2.py`
- `backend/tests/test_scene_steps_v3.py`
- `backend/tests/test_scene_verify_v2.py`
- `backend/tests/test_outlook_v2.py`

패턴:

- step ordering, label, class binding, sync projection, v2/v3 path 가정이 현재 manifest와 다르다.
- 이 실패들은 "낡은 테스트"이면서 동시에 "현재 문서와 구현이 얼마나 많이 바뀌었는지"를 보여주는 지표다.

#### C. text/entity/scene contract drift

- `backend/tests/test_text_cleanup.py`
- `backend/tests/test_entity_extract_v4.py`
- `backend/tests/test_entity_filter.py`
- `backend/tests/test_entity_review_v4.py`
- `backend/tests/core/test_location_consistency.py`
- `backend/tests/core/test_scene_detail_analyze_one.py`

패턴:

- 공개 함수 import 경로, low-frequency filter 결과, scene detail prompt shaping 등에서 테스트와 구현이 어긋난다.
- 특히 `test_text_cleanup.py`는 `clean_text` import 자체가 실패한다.

#### D. variation / image API drift

- `backend/tests/test_images_api.py`
- `backend/tests/test_entities_api.py`
- `backend/tests/test_variation_pipeline.py`

패턴:

- still response shape 차이
- `VariationRecommender` 생성자 시그니처 차이
- angle edit prompt 내용 차이
- version registry 값 drift

의미:

- 이미지/variation 영역은 리팩토링 이후에도 테스트 기준선을 아직 새 구조에 맞게 충분히 재고정하지 못했다.

## 2. 프런트 품질 상태 해석

### 2.1 빌드는 되지만 품질 게이트는 아니다

`npm run build`는 통과하지만, 결과는 곧바로 "출시 준비 완료"를 뜻하지 않는다.

- 최종 JS chunk: `987.79 kB`
- Vite 경고: 500kB 초과 chunk

이 수치는 route-level code splitting이나 editor-heavy 화면 분리가 거의 없다는 신호다.

### 2.2 lint 실패는 구조적 문제의 표면이다

주요 실패 파일:

- `frontend/src/components/episode/EpisodeStills.tsx`
- `frontend/src/components/shared/SceneVariationCard.tsx`
- `frontend/src/components/shared/ImageGalleryModal.tsx`
- `frontend/src/components/shared/PipelineStepsPanel.tsx`
- `frontend/src/pages/ProjectDetail.tsx`
- `frontend/src/pages/EpisodeDetail.tsx`
- `frontend/src/pages/Episodes.tsx`

주요 유형:

- `@typescript-eslint/no-explicit-any`
- `@typescript-eslint/no-unused-vars`
- `react-hooks/exhaustive-deps`
- `react-hooks/set-state-in-effect`

해석:

- 페이지 상위 구조를 정리하는 데는 성공했지만, 하위 복잡도와 타입 부채가 아직 많이 남았다.
- 특히 `ImageGalleryModal.tsx`와 `useEventSource.ts`의 `set-state-in-effect`는 단순 미관 문제가 아니라 React 흐름 규칙 위반이다.

### 2.3 프런트는 테스트 부재가 가장 큰 운영 리스크다

현재 상태:

- `package.json`에 `test` 스크립트 없음
- `test/spec` 파일 없음

영향:

- React Query invalidation
- variation editor
- still mutation
- polling to terminal transition

이 네 영역은 수동 재현 비용이 높고 회귀가 조용히 들어오기 쉽다.

## 3. 현재 테스트 전략의 구조적 문제

현재 저장소는 세 종류의 검증이 한 lane에 섞여 있다.

1. 현재 구조를 검증하는 새 테스트
2. 옛 구조를 가정하는 회귀 테스트
3. 환경 의존성이 큰 통합/E2E 테스트

이 셋이 분리되지 않으니, 실패가 "새 버그"인지 "낡은 계약"인지 즉시 해석하기 어렵다.

## 4. 권장 품질 게이트

### 백엔드

- `lane A`: manifest/catalog/applicability/checkpoint IO/service 계약
- `lane B`: API/DB 통합
- `lane C`: full regression

각 lane은 다른 성공 기준을 가져야 한다.

### 프런트

- `npm run build`
- `npm run lint`
- smoke test 2~4개
- mutation hook / invalidation 테스트 몇 개

이 네 개가 최소선이다.

## 5. 결론

품질 상태를 한 문장으로 요약하면 이렇다.

"현재 저장소는 리팩토링 결과가 아예 불안정한 것은 아니지만, repo 전체 기준으로는 아직 배포 품질을 선언할 수 없고, 특히 테스트 계약과 프런트 정적 품질이 크게 뒤처져 있다."