배경
현재 이 저장소에는 테스트가 하나도 없고 CI도 없습니다.
package.json에 test 스크립트가 없고 테스트 러너 설정도 없습니다.github/ 디렉터리가 비어 있어 GitHub Actions 워크플로우가 없습니다AGENTS.md는 PR 전 bun run typecheck, bunx vp check, bun run build 통과를 요구하지만, 이를 자동으로 확인하는 장치가 없습니다
다행히 진입 비용은 낮습니다. Vite+ 툴체인에 vp test가 이미 포함되어 있어 러너를 새로 고를 필요가 없습니다.
먼저 짚고 갈 것 — 이 코드베이스의 특성
무작정 테스트를 늘리기 전에 무엇이 실제로 깨지는지부터 봐야 합니다.
이 저장소는 약 2,200줄인데 그중 src/styles/site.css가 1,520줄입니다. 로직이 거의 없고 마크업과 스타일이 대부분입니다. 그리고 지금까지 발견된 버그(#1~#7)는 전부 CSS 캐스케이드와 레이아웃 문제였습니다.
즉 컴포넌트 렌더 테스트를 아무리 촘촘히 써도 기존 버그 중 단 하나도 잡지 못합니다. 커버리지 숫자를 올리는 방향은 이 저장소에서 특히 효과가 없습니다.
이 이슈의 핵심 질문
이미 발생한 버그들이 다시 발생하지 않으려면, 그리고 이 저장소가 지켜야 할 원칙이 깨졌을 때 알아차리려면, 어떤 검사가 필요한가?
여기에 대한 답을 설계하고 구현하는 것이 이 이슈의 내용입니다. 아래 후보는 참고용이며, 다른 판단이 있다면 이슈에 근거와 함께 남기고 그쪽으로 진행해 주세요.
검토 후보
| 후보 |
무엇을 막는가 |
비고 |
sitemap.xml·llms.txt ↔ 라우트 동기화 검사 |
AGENTS.md의 "라우트를 추가하면 sitemap과 llms.txt도 갱신한다"는 수동 규칙. 수동 규칙은 결국 깨집니다 |
ROI가 가장 높다고 봅니다 |
| prerender 스모크 테스트 |
SEO는 이 저장소의 필수 원칙인데 현재 검증이 전혀 없습니다. 각 라우트가 정적 HTML로 생성되는지, title·description·canonical·hreflang이 포함되는지 |
#10과 직접 연관 |
| i18n 쌍 런타임 검증 |
Messages 타입이 키 존재는 강제하지만, 배열 길이 불일치나 빈 문자열은 잡지 못합니다 |
카피 수정 시 자주 발생 |
| 시각적 회귀 테스트 |
#1~#7 같은 레이아웃 버그 |
유지비가 크므로 도입 여부부터 판단이 필요합니다 |
함께 필요한 것: CI
테스트를 만들어도 돌릴 곳이 없으면 아무도 실행하지 않습니다. GitHub Actions 워크플로우도 함께 만들어야 합니다.
- PR과 main push에서 실행
- 최소
typecheck, vp check, build, 그리고 새로 만든 테스트
- Bun 사용 (
devEngines에 bun@1.3.14 지정됨)
- 배포는 Cloudflare Workers Builds가 main push 시 자동으로 수행하므로, CI는 검증만 담당하면 됩니다
액션 버전 고정과 권한 최소화 등 워크플로우 보안 관례도 함께 지켜 주세요.
완료 기준
범위 밖
- 커버리지 목표치 설정 — 이 저장소에서는 의미가 크지 않습니다
- 전체 컴포넌트에 대한 렌더 테스트 작성
참고
배경
현재 이 저장소에는 테스트가 하나도 없고 CI도 없습니다.
package.json에test스크립트가 없고 테스트 러너 설정도 없습니다.github/디렉터리가 비어 있어 GitHub Actions 워크플로우가 없습니다AGENTS.md는 PR 전bun run typecheck,bunx vp check,bun run build통과를 요구하지만, 이를 자동으로 확인하는 장치가 없습니다다행히 진입 비용은 낮습니다. Vite+ 툴체인에
vp test가 이미 포함되어 있어 러너를 새로 고를 필요가 없습니다.먼저 짚고 갈 것 — 이 코드베이스의 특성
무작정 테스트를 늘리기 전에 무엇이 실제로 깨지는지부터 봐야 합니다.
이 저장소는 약 2,200줄인데 그중
src/styles/site.css가 1,520줄입니다. 로직이 거의 없고 마크업과 스타일이 대부분입니다. 그리고 지금까지 발견된 버그(#1~#7)는 전부 CSS 캐스케이드와 레이아웃 문제였습니다.즉 컴포넌트 렌더 테스트를 아무리 촘촘히 써도 기존 버그 중 단 하나도 잡지 못합니다. 커버리지 숫자를 올리는 방향은 이 저장소에서 특히 효과가 없습니다.
이 이슈의 핵심 질문
여기에 대한 답을 설계하고 구현하는 것이 이 이슈의 내용입니다. 아래 후보는 참고용이며, 다른 판단이 있다면 이슈에 근거와 함께 남기고 그쪽으로 진행해 주세요.
검토 후보
sitemap.xml·llms.txt↔ 라우트 동기화 검사AGENTS.md의 "라우트를 추가하면 sitemap과 llms.txt도 갱신한다"는 수동 규칙. 수동 규칙은 결국 깨집니다Messages타입이 키 존재는 강제하지만, 배열 길이 불일치나 빈 문자열은 잡지 못합니다함께 필요한 것: CI
테스트를 만들어도 돌릴 곳이 없으면 아무도 실행하지 않습니다. GitHub Actions 워크플로우도 함께 만들어야 합니다.
typecheck,vp check,build, 그리고 새로 만든 테스트devEngines에bun@1.3.14지정됨)액션 버전 고정과 권한 최소화 등 워크플로우 보안 관례도 함께 지켜 주세요.
완료 기준
vp test로 실행되는 테스트 설정이 갖춰짐package.json에test스크립트 추가AGENTS.md의 PR 전 체크리스트에 테스트가 반영됨범위 밖
참고
/about), 영어가/en미러(/en/about)이며 두 로케일 라우트가 항상 쌍으로 존재해야 합니다. 검사를 설계할 때 이 구조를 고려해 주세요