[1팀 이은지] Chapter 3-2 프론트엔드 테스트 코드

.cursor/rules/assignment.mdc

@@ -0,0 +1,109 @@
+---
+alwaysApply: true
+---
+
+## (1) 요구사항 추가
+
+1. **(필수) 반복 유형 선택**
+   - 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
+   - 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
+     - 31일에 매월을 선택한다면 → 매월 마지막이 아닌, 31일에만 생성하세요.
+     - 윤년 29일에 매년을 선택한다면 → 29일에만 생성하세요!
+2. **(필수) 반복 일정 표시**
+   - 캘린더 뷰에서 반복 일정을 아이콘을 넣어 구분하여 표시한다.
+3. **(필수) 반복 종료**
+   - 반복 종료 조건을 지정할 수 있다.
+   - 옵션: 특정 날짜까지
+     - 예제 특성상, 2025-10-30까지 최대 일자를 만들어 주세요.
+4. **(필수) 반복 일정 단일 수정**
+   - 반복일정을 수정하면 단일 일정으로 변경됩니다.
+   - 반복일정 아이콘도 사라집니다.
+5. **(필수) 반복 일정 단일 삭제**
+   - 반복일정을 삭제하면 해당 일정만 삭제합니다.
+
+## (2) TDD 기반으로 코드 작성하기
+
+<aside>
+💡 main 브랜치를 기준으로 코드를 작성해도 좋고, **이전 주차에 제출한 코드를 기반으로 작성해도 무방합니다.**
+
+</aside>
+
+아래의 순서를 기반으로 코드를 작성해주세요. 모든 요구사항을 기반으로 작성하지 않아도 좋습니다.
+
+1. 추가된 요구사항에 대해 실패하는 테스트 코드를 작성합니다.
+2. 추가된 요구사항에 대해 성공하는 테스트 코드를 작성합니다.
+3. 테스트 코드를 통과할 수 있도록 구현 코드(어플리케이션 코드)를 작성합니다.
+4. 1~3을 리팩토링합니다.
+
+## (3) 평가 기준
+
+1. TDD 프로세스 준수:
+   - 테스트를 먼저 작성하고 실패하는 것을 확인한 후 구현을 진행했는가?
+   - 각 요구사항에 대해 최소한의 코드로 테스트를 통과시켰는가?
+   - 테스트 통과 후 적절한 리팩토링을 수행했는가?
+2. 테스트 품질:
+   - 각 테스트가 하나의 동작 또는 기능만을 명확히 검증하고 있는가?
+   - 테스트가 요구사항을 정확히 반영하고 있는가?
+   - 모든 주요 기능과 시나리오(긍정적 케이스와 부정적 케이스 모두)에 대한 테스트가 작성되었는가?
+   - 경계값과 예외 상황에 대한 테스트가 포함되어 있는가?
+
+---
+
+심화과제
+
+## (1) 테스트 전략 수립
+
+학습자료 [8-2. 테스트 전략 작성해보기]의 내용을 참고해서 기본과제에서 구현한 내용에 대해 테스트 전략을 구상해보세요.
+
+> 제일 중요한 것은 결국 **내가 작성한 코드, 프로젝트의 신뢰성을 높이는 것**입니다.
+>
+> 적합하지 않은 테스트 종류를 선택해 무리하게 적용하기 보다는 각 테스트의 장점과 한계점을 명확하게 이해하고 **가장 효율적이고 장기적으로 운영 가능한 방식으로 테스트**를 설계해야 합니다.
+>
+> 만약 공통 컴포넌트나 리액트 훅과 같은 UI kit을 만드는 프로젝트를 진행하고 있다면, 통합 테스트나 복잡한 E2E 테스트보단 단위 테스트에서 각 컴포넌트의 기능이 올바르게 동작하는지 확인하는 것이 적합합니다.
+>
+> 반면 일반적인 서비스 앱을 만들고 있는 상황에서 비즈니스 로직을 검증할때는 단위 테스트 보다는 통합 테스트를 통해 검증하는 것이 효율적입니다.
+>
+> 이처럼 대상을 어떠한 범주에서 검증하는 것이 효과적인지 계속 따져보고 고민하는 것이 프런트엔드 테스트에서는 중요합니다.
+
+단위, 통합테스트가 부족한가요? 테스트를 보강해보세요! e2e 테스트나 시각적 테스트를 통해 신뢰도를 높일 수 있을 것 같나요!? 시도해보세요!
+
+## (2) 과제 진행 방법
+
+1. 팀원 모두 각자 이 프로젝트에 필요한 테스트 전략을 작성해본다.
+2. 정해진 시간에 모두 모여 각자의 테스트 전략을 공유해보고 모두가 공감할 수 있는 테스트 전략을 작성해본다. **_(PR 본문에 해당 결과에 도달하게 된 이유를 함께 작성해주세요)_**
+3. 테스트 전략에 맞춰 테스트 코드 작성해보기
+   1. 😄 *팀원들이 함께 페어 코딩으로 테스트를 작성해도 괜찮습니다. 코치님들이 채점하기 쉽도록 PR에 페어코딩으로 작성했다고 흔적을 남겨주세요! 작업자의 PR을 심화 링크로 제출해도 괜찮습니다.*
+   2. 😄 *합의를 한 테스트 전략에 맞춰 각자 테스트를 다른 스타일로 작성해도 괜찮습니다. 여기서 중요한 건 **합의를 한 테스트 전략**입니다. 토론을 꼭 해주세요.*
+
+## (3) 평가 기준
+
+- 각 요구사항에 대해 적절한 테스트 유형(단위, 통합, E2E 등)을 선택했는가?
+- 테스트 전략이 프로젝트의 특성과 각 요구사항의 중요도를 고려하여 수립되었는가?
+- 선택한 테스트 전략이 효율적이고 실행 가능한가?
+- 반드시 3개 이상의 추가 테스트가 작성되어야 합니다.
+  - 최소 갯수는 사실 학습의 의미는 없을 겁니다. 가능한한 유의미한 테스트를 많이 만들어보세요.
+
+# 체크리스트
+
+아래 체크리스트를 준수했는지 체크해줘.
+
+- 코드가 Prettier를 통해 일관된 포맷팅이 적용되어 있는가?
+- 적절한 줄바꿈과 주석을 사용하여 코드의 논리적 단위를 명확히 구분했는가?
+- 변수명과 함수명이 그 역할을 명확히 나타내며, 일관된 네이밍 규칙을 따르는가?
+- 매직 넘버와 문자열을 의미 있는 상수로 추출했는가?
+- 중복 코드를 제거하고 재사용 가능한 형태로 리팩토링했는가?
+- 함수가 단일 책임 원칙을 따르며, 한 가지 작업만 수행하는가?
+- 조건문과 반복문이 간결하고 명확한가? 복잡한 조건을 함수로 추출했는가?
+- 코드의 배치가 의존성과 실행 흐름에 따라 논리적으로 구성되어 있는가?
+- 연관된 코드를 의미 있는 함수나 모듈로 그룹화했는가?
+- ES6+ 문법을 활용하여 코드를 더 간결하고 명확하게 작성했는가?
+- 전역 상태와 부수 효과(side effects)를 최소화했는가?
+- 에러 처리와 예외 상황을 명확히 고려하고 처리했는가?
+- 코드 자체가 자기 문서화되어 있어, 주석 없이도 의도를 파악할 수 있는가?
+- 비즈니스 로직과 UI 로직이 적절히 분리되어 있는가?
+- 객체지향 또는 함수형 프로그래밍 원칙을 적절히 적용했는가?
+- 코드의 각 부분이 테스트 가능하도록 구조화되어 있는가?
+- 성능 개선을 위해 불필요한 연산이나 렌더링을 제거했는가?
+- 새로운 기능 추가나 변경이 기존 코드에 미치는 영향을 최소화했는가?
+- 리팩토링 시 기존 기능을 그대로 유지하면서 점진적으로 개선했는가?
+- 코드 리뷰를 통해 다른 개발자들의 피드백을 반영하고 개선했는가?

.cursor/rules/clean-code.mdc

@@ -0,0 +1,96 @@
+---
+alwaysApply: true
+---
+
+# Clean Code Writing Rules
+
+## MANDATORY CODE WRITING RULES
+
+You MUST follow these rules when writing any code:
+
+### CORE DESIGN PRINCIPLES
+
+- **DRY**: NEVER repeat the same code
+- **KISS**: Write code as simply as possible
+- **YAGNI**: Do NOT write unnecessary code
+- **Single Responsibility**: Functions MUST be under 20 lines and have ONE clear responsibility
+
+### CODE ORGANIZATION RULES
+
+Apply these 4 organization principles:
+
+- **Proximity**: Group related elements with blank lines
+- **Commonality**: Group related functionality into functions
+- **Similarity**: Use similar names and positions for similar roles
+- **Continuity**: Arrange code in dependency order
+
+### NAMING REQUIREMENTS
+
+#### Naming Principles (ALL MUST BE FOLLOWED)
+
+1. **Predictable**: Name must allow prediction of value, type, and return value
+2. **Contextual**: Add descriptive adjectives or nouns for context
+3. **Clear**: Remove unnecessary words while maintaining clear meaning
+4. **Concise**: Brief yet clearly convey role and purpose
+5. **Consistent**: Use identical terms for identical intentions across entire codebase
+
+#### REQUIRED Naming Patterns
+
+**Action Functions - USE THESE PATTERNS:**
+
+```
+// Creation: create~(), add~(), push~(), insert~(), new~(), append~(), spawn~(), make~(), build~(), generate~()
+// Retrieval: get~(), fetch~(), query~()
+// Transformation: parse~(), split~(), transform~(), serialize~()
+// Modification: update~(), mutation~()
+// Deletion: delete~(), remove~()
+// Communication: put~(), send~(), dispatch~(), receive~()
+// Validation: validate~(), check~()
+// Calculation: calc~(), compute~()
+// Control: init~(), configure~(), start~(), stop~()
+// Storage: save~(), store~()
+// Logging: log~(), record~()
+```
+
+**Data Variables - USE THESE PATTERNS:**
+
+```
+// Quantities: count~, sum~, num~, min~, max~, total
+// State: is~, has~, current~, selected~
+// Progressive/Past: ~ing, ~ed
+// Information: ~name, ~title, ~desc, ~text, ~data
+// Identifiers: ~ID, ~code, ~index, ~key
+// Time: ~at, ~date
+// Type: ~type
+// Collections: ~s
+// Others: item, temp, params, error
+// Conversion: from(), of()
+```
+
+### ABSTRACTION RULES
+
+- **Data Abstraction**: Simplify data structure and processing methods
+- **Process Abstraction**: Encapsulate complex logic into simple interfaces
+- **Appropriate Level**: Do NOT over-abstract or under-abstract
+
+### MANDATORY CHECKLIST
+
+Before finalizing ANY code, you MUST verify:
+
+1. ✅ **Applied standard naming patterns** from above
+2. ✅ **Organized code using 4 organization principles**
+3. ✅ **Split complex logic into small functions**
+4. ✅ **Code expresses intent without comments** (comments only when absolutely necessary)
+5. ✅ **Maintained consistent formatting**
+
+### FORBIDDEN PRACTICES
+
+- ❌ Do NOT mix similar terms (`display` vs `show`)
+- ❌ Do NOT write functions longer than 20 lines
+- ❌ Do NOT repeat code patterns
+- ❌ Do NOT use unclear or ambiguous names
+- ❌ Do NOT violate naming consistency across codebase
+
+## COMPLIANCE REQUIREMENT
+
+ALL code output MUST comply with these rules. No exceptions.