[3팀 박준형] Chapter 🦍 3-1. 프론트엔드 테스트 코드 🦍

.cursorrules

@@ -0,0 +1,119 @@
+# 테스트 코드 작성 철학 및 가이드라인
+
+## 핵심 철학
+- **좋은 테스트코드 = 실행 가능한 명세서**: 기능의 의도와 기대 동작을 사람이 읽기 쉽게 작성하고, 리팩터링에도 안정적으로 동작해야 함
+- **가독성과 안정성이 최우선**: DRY보다 DAMP(Descriptive And Meaningful Phrases) 원칙을 따름
+- **행위 중심 검증**: 구현 세부사항이 아닌 관찰 가능한 결과를 검증
+
+## 구체적 원칙
+
+### 1. 의도 우선 가독성
+- 테스트 이름은 문장형으로 작성 (무엇을/언제/어떻게)
+- AAA(Arrange-Act-Assert) 또는 Given-When-Then 구조 사용
+- 최소한의 제어 흐름(if/loop)만 사용
+- 각 테스트가 자신이 무엇을 검증하는지 명확히 드러내야 함
+
+### 2. 의미 있는 중복 허용 (DAMP 원칙)
+- **허용되는 중복**: 각 테스트가 자신의 맥락과 기대값을 스스로 드러낼 때
+- **금지되는 중복**: 의도를 흐리거나 유지보수 비용만 늘리는 경우
+- 과도한 헬퍼/추상화는 자제 - 테스트 스펙이 헬퍼 뒤에 숨겨지면 안됨
+- 기대값은 테스트 내에서 "그대로" 명시하여 의도를 드러냄
+
+### 3. 구현 디테일 비의존
+- 내부 함수 호출 횟수, 구체적인 알고리즘, 비공개 상태 검증 금지
+- 결과/화면/외부 인터페이스와 같은 관찰 가능한 동작만 검증
+- 코드가 리팩터링되어도 테스트가 깨지지 않아야 함
+
+### 4. 결정론적이고 고립된 테스트
+- 시간/랜덤/네트워크 등 외부 요인 제어로 Flaky 테스트 제거
+- 테스트 간 상태 공유 금지
+- 각 테스트는 독립적으로 실행 가능해야 함
+
+### 5. 단일 실패 원칙
+- 한 테스트는 한 행동 단위만 검증
+- 여러 단언문은 동일 행동에 대한 다양한 측면을 검증할 때만 허용
+- 하나의 명확한 이유로만 실패해야 함
+
+### 6. 유지보수 용이성
+- 필요 이상의 글로벌 훅/픽스처 지양
+- "중복이 의미를 줄 때는 인라인", "노이즈일 때만 빌더/헬퍼 사용"
+- 테스트가 변경되어야 하는 이유를 최소화
+
+### 7. 적절한 테스트 조합
+- 단위 테스트: 빠르고 촘촘하게
+- 통합/E2E 테스트: 적절한 수준으로
+- 팀과 도메인에 맞는 테스트 피라미드/트로피 구성
+
+### 8. 견고한 단언
+- 스냅샷 테스트 남용 금지, 꼭 필요한 형태만 사용
+- 중요한 속성만 명시적으로 `toEqual`/커스텀 매처로 검증
+- 의미 있는 에러 메시지 제공
+
+### 9. 커버리지는 수단
+- 숫자 자체가 목표가 아님
+- 핵심 시나리오/경계값/회귀 케이스를 우선적으로 커버
+- 의미 있는 테스트가 자연스럽게 높은 커버리지를 만들어냄
+
+## 테스트 스멜 감지 및 리팩터링 대상
+
+### 즉시 리팩터링해야 하는 스멜들
+- `sleep`이나 임의의 대기 시간 사용
+- 랜덤 값에 의존하는 테스트
+- 과도한 목(Mock) 체이닝
+- 마법 같은 픽스처나 전역 상태
+- 지나친 DRY로 인한 가독성 저하
+- 애매하거나 의미 없는 테스트 이름
+- 구현 세부사항에 강하게 결합된 테스트
+
+## 코드 예시
+
+### ✅ 선호하는 스타일 (의미 있는 중복)
+```typescript
+it('검색어 "Event"는 주간 뷰에서 2025-07-01~07-07 범위의 매칭 이벤트만 반환한다', () => {
+  const result = getFilteredEvents(events, 'Event', new Date('2025-07-01'), 'week');
+
+  expect(result).toEqual([
+    {
+      id: '1',
+      title: 'Event 1',
+      date: '2025-07-01',
+      // ... 명시적인 기대값
+    },
+    {
+      id: '2', 
+      title: 'Event 2',
+      date: '2025-07-02',
+      // ... 명시적인 기대값
+    }
+  ]);
+});
+```
+
+### ❌ 비선호하는 스타일 (과도한 추상화)
+```typescript
+it('검색 필터가 동작한다', () => {
+  const result = runSearchHelper('Event', '2025-07-01', 'week');
+  expectIds(result).toEqual(['1', '2']); // 스펙이 헬퍼 뒤에 숨음
+});
+```
+
+## 헬퍼 사용 가이드라인
+
+### 헬퍼를 만들어도 되는 경우
+- 반복되는 도메인 객체 생성 (빌더 패턴)
+- 의미를 전달하는 커스텀 매처
+- 복잡한 셋업이 테스트 의도를 가리는 경우
+
+### 헬퍼를 만들지 말아야 하는 경우
+- 단순한 중복 제거만이 목적인 경우
+- 테스트의 기대값이나 핵심 로직을 숨기는 경우
+- 헬퍼가 테스트보다 복잡해지는 경우
+
+## 이 프로젝트 적용 시 주의사항
+- 기대 객체를 테스트 안에서 "그대로" 명시하여 의도를 드러낼 것
+- 내부 구현이 바뀌어도 통과해야 하는 "행동"을 주 단언 대상으로 할 것
+- 각 테스트 케이스가 어떤 시나리오를 검증하는지 이름만 봐도 알 수 있게 작성할 것
+
+---
+
+**기억할 것: 읽는 사람이 설계 의도를 오해 없이 파악하고, 코드가 바뀌어도 테스트가 합리적인 이유로 실패/성공하도록 작성하는 것이 목표**

README.md

@@ -1,4 +1,4 @@
-# 7주차 테스트 과제
+# 7주차 테스트 과제(박준형)
 
 ## 난이도 선택 가이드
 

eslint.config.js

@@ -70,7 +70,8 @@ export default [
       ...typescriptPlugin.configs.recommended.rules,
 
       // ESLint rules
-      'no-unused-vars': 'warn',
+      'no-unused-vars': 'off',
+      '@typescript-eslint/no-unused-vars': ['error'],
 
       // React rules
       'react/prop-types': 'off',

package.json

@@ -19,14 +19,17 @@
   "dependencies": {
     "@emotion/react": "^11.11.4",
     "@emotion/styled": "^11.11.5",
+    "@eslint/js": "^9.33.0",
     "@mui/icons-material": "7.2.0",
     "@mui/material": "7.2.0",
     "express": "^4.19.2",
     "framer-motion": "^12.23.0",
     "msw": "^2.10.3",
     "notistack": "^3.0.2",
+    "overlay-kit": "^1.8.4",
     "react": "19.1.0",
-    "react-dom": "19.1.0"
+    "react-dom": "19.1.0",
+    "valtio": "^2.1.7"
   },
   "devDependencies": {
     "@testing-library/jest-dom": "^6.6.3",