Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/good-code/2-quality.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ import DevilsAdvocate from '@site/src/components/DevilsAdvocate';

- 20장 — 단일 기법으로 결함의 60%도 못 잡는다는 전제는 타입·린터·테스트·리뷰가 일상이 된 2026년 FE에서 오히려 더 잘 들어맞아요.
- 21장 — 코드 리뷰·페어·CI·QA를 한 파이프라인으로 보면 "결함 발견 시점을 얼마나 앞당기느냐"가 팀 비용을 가르는 축이 돼요.
- 22장 — 단위 테스트는 여전히 기본기지만, 컴포넌트와 Playwright가 섞인 FE에서는 "테스트 피라미드 vs 트로피"의 선택이 함께 따라와요.
- 22장 — 단위 테스트는 여전히 기본기지만, 컴포넌트 테스트와 Playwright가 결합된 FE에서는 "테스트 피라미드 vs 트로피"의 선택이 함께 따라와요.
- 23장 — 디버깅은 가설 수립과 이분 탐색 같은 개인 사고력 + Sentry/Session Replay 같은 팀 인프라가 양쪽 다 필요한 영역이에요.

큰 그림을 훑었으니, 각 장의 판정과 체크, 그리고 미션 산출물로 들어가 볼게요.
Expand Down Expand Up @@ -260,7 +260,7 @@ describe('pay', () => {

```text
코딩 ──→ 셀프 체크 ──→ 코드 리뷰 ──→ CI ──→ QA ──→ 릴리스
① ② ③
```

#### 설계 노트
Expand Down Expand Up @@ -301,7 +301,7 @@ describe('pay', () => {

<Verdict
rating="🟢 생존"
rationale={`"코드 작성 전에 테스트를 설계하라", "경계값·나쁜 데이터·정상 데이터 클래스를 체계적으로 만들라"는 원칙은 Vitest·Testing Library·Playwright가 도구를 바꿨을 뿐, 테스트 설계의 사고방식 자체는 그대로 유효하다.`}
rationale={`"코드 작성 전에 테스트를 설계하라", "경계값·나쁜 데이터·정상 데이터 클래스를 체계적으로 만들라"는 원칙은 Jest·Vitest·React Testing Library·Playwright가 도구를 바꿨을 뿐, 테스트 설계의 사고방식 자체는 그대로 유효하다.`}
/>

### ✅ 체크리스트
Expand Down
Loading