[Test] #293 - Domain 4개 모듈 테스트를 기능 명세로 재작성하고 검증 도구 추가

[Naknakk]

💡 Issue

• closed [Test] Domain 테스트를 기능 명세로 재작성하고 검증 도구 추가 #293

💭 Summary

AI가 코드를 쓰고 리뷰까지 하면서, 사람이 구현 코드를 다 읽는 게 병목이 됐어요.

그래서 사람은 테스트를 보고 믿을 수 있게 만들었어요.
Domain 4개 모듈(Auth·NovelReview·BaseDomain·Collection)의 테스트를 "읽히는 기능 명세"로 다시 썼어요.
그리고 그 테스트가 믿을 만한지 기계가 검사하게 했어요.

🔑 Key Changes

1. 테스트를 기능 명세로 재작성

• 테스트 이름이 화면에서 일어나는 일을 한국어 문장으로 말해요.
  • 예: "대표로 고른 작품을 빼면 대표 선택도 풀린다"
• 저장소에 넘기기만 하는 UseCase의 테스트 17개는 지웠어요. 지킬 규칙이 없는 코드라서요.
• 그 결과 쓰지 않게 된 Auth·Collection의 .testing 타깃과 Mock도 지웠어요.
• 테스트가 많은 파일 5개는 주제별 하위 @Suite로 나눴어요.
  • 예: 컬렉션 만들기·수정하기 → 이름 / 작품 추가·빼기 / 대표 작품 고르기 …
  • 목록 파일(TEST_SPEC.md)에도 부모 아래 소제목(###)으로 나와요.
  • 나누는 기준은 개수가 아니라 개념이에요(docs/TESTING.md).
• 테스트 수(@Test): 186개 → 123개
  • Auth 18 → 13, NovelReview 35 → 15, BaseDomain 65 → 57, Collection 68 → 38

2. ArchLint 테스트 명세 규칙 (Tooling/ArchLint)

• 규칙 14개와 목록 파일 검사를 추가했어요. 모두 CI의 Architecture Rules job에서 돌아요.
• 이름, 위치, 확인 방법, 결과만 보기, 늘 같은 결과, 준비·실행·확인 구조를 봐요.
  • 예: != nil만 확인하기 금지, Date()·Calendar.current 금지, 넘기기만 하는 UseCase 테스트 금지
• 규칙에 예외가 필요하면 // archlint:allow <규칙> — 이유 주석을 달아요.
  • 이 주석은 테스트 규칙에만 통해요. 아키텍처 규칙은 끌 수 없어요.
• 지금은 위 4개 모듈에만 켜져 있어요(TestSpecScope.modules).

3. 테스트 목록 파일 (TEST_SPEC.md)

• 모듈마다 스위트와 테스트 이름을 모은 파일이에요. ArchLint가 만들고, 최신인지도 검사해요.
• PR에서는 이 파일의 diff로 "어떤 동작이 생기고 바뀌었는지"를 먼저 볼 수 있어요.

4. 뮤테이션 도구 (Mutate)

• 소스에 버그를 하나씩 심고, 테스트가 잡는지 확인해요.
  • 예: <를 <=로 바꾸기, 문장 하나 지우기
• 살아남은 버그는 "테스트가 지키지 못하는 동작"이라 사람이 판단해요.
• 로컬에서 수동으로 돌려요: swift run --package-path Tooling/ArchLint Mutate <모듈>
• 도중에 끊거나 실행이 실패해도 소스를 원본으로 되돌려요.

5. 소스 변경 (3곳)

• CollectionDraft.setNovels: 같은 작품이 두 번 들어오면 duplicatedNovel로 거부해요.
  • 전에는 addNovel만 막아서 들어오는 길마다 규칙이 달랐어요.
• ReadingPeriod: calendar 인자를 추가했어요(기본값 있음). 테스트가 기기 시간대와 상관없이 같은 결과를 내게 하려고요.
• MockKeywordRepository: 몇 번 불렀는지 대신 "동기화했는지"와 "검색어"에 따라 답을 바꿔요.

6. 문서

• docs/TESTING.md를 "테스트가 지켜야 할 5가지" 중심으로 다시 썼어요.
• 루트·Domain CLAUDE.md, WORKFLOW.md, DEFINITION_OF_DONE.md, wss-pr-reviewer, new-module 스킬도 맞췄어요.

📱 Simulation

해당 없음(테스트·도구·문서 변경이에요).

🧑‍🧒‍🧒 To Reviewer

어디부터 읽으면 좋은지

1. 각 모듈의 TEST_SPEC.md: 빠진 규칙이 없는지, 원하는 동작인지 봐 주세요.
2. 테스트 본문: 이름대로 확인하는지 봐 주세요.
3. 기계가 확신하지 못한 곳:
   • allow 주석 1건: RatingTests.swift의 "0.5점 단위"(숫자가 넣는 값이 아니라 단위를 말해요)
   • 뮤테이션에서 살아남았지만 "의미 없음"으로 판단한 버그 3개(BaseDomain)

측정 결과

옛 테스트에 지금 규칙을 돌려 봤어요(develop 기준).

• 위반: error 269건, warning 38건
• 그중 가짜 테스트 58건
  • 넘기기만 하는 코드를 테스트: 17
  • != nil만 확인: 14
  • 이름의 숫자가 본문에 없음: 9
  • 조회 횟수를 세는 Mock: 8
  • 소스 상수로 기대값을 씀: 4
  • Calendar.current에 기댐: 4
  • 판단 코드인데 테스트가 없음: 2(Rating, ReadingPeriod)
• 규칙 오탐: 1건 찾아서 고쳤어요(test-source-constant).

뮤테이션(심은 버그 중 테스트가 잡은 수):

• Auth 14/14
• NovelReview 20/22 → 테스트를 더해 막았어요.
• BaseDomain 64/68 → 1개는 테스트를 더했고, 3개는 의미 없는 버그로 판단했어요.
• Collection 58/58

리뷰에서 나온 것

• wss-pr-reviewer와 Codex로 3라운드 리뷰했어요. 고친 내용은 마지막 커밋 6개([Fix]·[Test]·[Docs])에 있어요.
• 마지막 라운드에서 wss-pr-reviewer는 🔴 0 🟡 0이었어요.
• Codex의 마지막 지적 4개는 고쳤지만, 고친 뒤에 다시 리뷰하지는 않았어요.

알고 있는 한계

• "판단 코드에 테스트가 있는가" 규칙은 테스트가 그 타입을 언급하는지만 봐요. 제대로 확인하는지는 뮤테이션 도구가 맡아요.
• 테스트는 적은 것만 지켜요. 화면, 비동기 경합, 서버 매핑은 이 PR의 범위 밖이에요.
• 뮤테이션 결과는 리뷰 수정 전에 잰 숫자예요. 리뷰 때 더한 테스트는 반영되지 않았어요.

확인 부탁

• 뮤테이션 도구가 Linux CI(swift:6.3.3 컨테이너)에서 빌드되는지는 이 PR의 Architecture Rules 결과로 처음 확인해요.

※ Reference

• docs/TESTING.md: 테스트가 지켜야 할 5가지, 작업 순서, 사람이 보는 곳
• Tooling/ArchLint/README.md: 규칙 목록과 뮤테이션 도구
• 후속 작업: [Setting] TDD 훅과 테스트 작성 전용 agent 도입 #294 (TDD 훅, 테스트 작성 전용 agent)

🤖 Generated with Claude Code

https://claude.ai/code/session_015vk4VehJFcSyPXzh7syk9V

[github-actions]

테스트 커버리지 리포트

Module	Coverage
AuthData	55.3%
AuthDomain	41.8%
BaseDomain	87.5%
CollectionDomain	63.1%
CollectionFeature	0.0%
CommentData	0.0%
CommentDomain	94.9%
FeedData	62.8%
FeedDomain	98.7%
HomeFeature	0.0%
LibraryFeature	0.0%
NotificationData	33.9%
NotificationDomain	100.0%
NotificationFeature	0.0%
NovelData	15.4%
NovelDetailFeature	0.0%
NovelDomain	92.9%
NovelReviewData	77.4%
NovelReviewDomain	71.4%
NovelReviewFeature	5.3%
ProfileData	46.1%
ProfileDomain	97.1%
RecommendationData	54.7%
RecommendationDomain	91.7%
SearchData	5.1%
SearchDomain	100.0%
SettingData	31.1%
SettingDomain	99.0%
SocialData	53.4%
SocialDomain	87.5%
SplashData	77.1%
SplashDomain	95.5%
SplashFeature	32.9%

_{Generated by CI on 2026-10-16 18:16 KST}

[Naknakk]

MARK -> SUITE 로 구분 기준 변경 & SUITE내에 SUITE를 넣어서 테스트 그룹 사이의 관계를 더 명확히 표현.
TAG 사용 개념도 찾아보기.