c3ddd36c6f
Some checks failed
deploy-site / deploy (push) Failing after 40s
Release notes for 1.1.0 were split between an Unreleased section and the version section, so the published notes would have omitted the update-feed and desktop changes. Everything shipping in this version now sits under one `## [1.1.0]` heading. `docs/map/` becomes the entry point for what infrastructure exists per platform and how far each feature is developed, with a documented update protocol so feature work and this map do not drift apart again. The release guide now states that installer binaries live in the update feed rather than the repository.
99 lines
5.1 KiB
Markdown
99 lines
5.1 KiB
Markdown
# 04 · 긴 시나리오(Long Scenario)로 RED 재구성
|
||
|
||
**목적**: 무수한 미시(단위) RED를 "사용자가 겪는 **긴 여정(장면)**" 단위로 재구성한다.
|
||
RED(테스트)는 단일 행위의 단일 테스트로 고정하되, 테스트를 **긴 시나리오(행위 사양)에서 파생**시킨다. 장면 단위를 "시나리오/행위 사양", 그에서 나온 테스트를 "미시 RED"로 용어 구분한다.
|
||
이로써 미시 RED 난립을 막고, 행위 완성도(traceability)와 에이전트 제어성을 동시에 얻는다.
|
||
|
||
---
|
||
|
||
## 왜 긴 시나리오인가
|
||
|
||
- **Beck(Canon TDD)의 1단계가 곧 긴 시나리오**: "며칠 동안 안 쓰던 기능까지 전부(행위 변형 목록) 나열하라." 마이크로부터 시작하면 완성도를 놓친다.
|
||
- **Alderson(2026)**: 티켓마다 "구현 전에 **테스트 계획**(통상 사용 + 엣지 + 커버 방식)"을 논의 — 이것이 곧 시나리오 명세.
|
||
- **SDD(2026)**: 수용 시나리오 → 테스트 매트릭스 → Test ID → 파일(추적).
|
||
- **테스트 피라미드(56)**: 행위는 **최저 충분 계층**에서 검증 — 같은 시나리오를 전 계층에 중복 금지.
|
||
- **Shore**: 수용은 "대화"가 본질 — 시나리오는 그 대화를 구조화한 산출물.
|
||
|
||
---
|
||
|
||
## 긴 시나리오 템플릿 (Gherkin 계열)
|
||
|
||
```gherkin
|
||
Feature: (사용자 가치를 하나의 문장으로)
|
||
|
||
Scenario: (한 장면의 제목)
|
||
Given <초기 상태 / 사전조건>
|
||
And <추가 상태>
|
||
When <행위/사건>
|
||
Then <관찰 가능한 결과 1>
|
||
And <관찰 가능한 결과 2>
|
||
And <부수 효과/경계/오류 투명성>
|
||
```
|
||
|
||
**좋은 예** (올바른 것을 만드는가 + 만드는 방법 모두 명세):
|
||
|
||
```gherkin
|
||
Feature: 계정 잠금
|
||
Scenario: 반복 실패 후 계정 잠금
|
||
Given 활성 계정
|
||
And 4회 연속 로그인 실패
|
||
When 잘못된 비밀번호 1개 더 제출
|
||
Then 인증은 실패해야 한다
|
||
And 계정은 15분 잠금
|
||
And 보안 이벤트가 기록된다
|
||
```
|
||
|
||
**원칙**: `Then`은 내부 구현이 아니라 **사용자/외부 시스템이 보는 결과**여야 한다(44).
|
||
=> `freeShippingFlag` 같은 내부 플래그 대신 `배송비 = 0`을 단정.
|
||
|
||
---
|
||
|
||
## 시나리오 → 테스트 매트릭스 (long → short 전개)
|
||
|
||
한 긴 시나리오를 **가장 낮은 충분 계층**의 테스트로 분해하되, 각 미시 RED에 추적 ID를 단다.
|
||
|
||
| Scenario (long) | 계층 | RED (short) | Test ID |
|
||
|---|---|---|---|
|
||
| 정상 주문 결제 | 단위 | 할인율 계산 정확 | T-101 |
|
||
| 정상 주문 결제 | 단위 | 배송비 경계(49.99/50/100, 음수 오류) | T-102 |
|
||
| 정상 주문 결제 | 통합 | 주문 저장→조회 왕복 | T-201 |
|
||
| 정상 주문 결제 | 계약 | 결제 게이트웨이 계약 | T-301 |
|
||
| 반복 실패 잠금 | 단위 | 시도 카운터·잠금 임계 | T-110 |
|
||
| 반복 실패 잠금 | 통합 | 보안 이벤트 기록 | T-210 |
|
||
| 정상 주문 결제 | E2E(PR) | 로그인→장바구니→결제→확인 (임계 여정만) | T-401 |
|
||
|
||
- **각 미시 RED는 02의 '의미 있는 RED' 12가지 중 하나여야** 한다.
|
||
- **같은 시나리오를 모든 계층에 중복하지 않는다**(57). E2E에서 결함 발견 시 **최저 계층**에 회귀 추가.
|
||
- **프로퍼티/계약/뮤테이션**을 필요한 곳에 보강(예: 파서·인코더·금융·인가).
|
||
|
||
---
|
||
|
||
## 긴 시나리오 × 에이전트 조율 (2026)
|
||
|
||
```
|
||
1. 스펙(스토리) 작성 ← 인간이 "올바른 것" 결정 (SDD)
|
||
2. 긴 수용 시나리오 명세 ← Given/When/Then, 인간 + 에이전트 논의(Alderson)
|
||
3. 보호(protected) 수용 테스트 ← 보호 경로에 배치·에이전트 수정 차단(92; 숨김은 이 환경에서 실행 불가 — 05 §2 다운그레이드)
|
||
4. RED: 에이전트가 시나리오별 의미 있는 단위 RED 생성
|
||
· "실제 이 브랜치가 발동하는 실례" 요구(76) — expect(1+1) 방지
|
||
5. GREEN: 최소 구현, 테스트 수정 금지(two hats, 11/100), 가장 단순한 변경(Probity, 78)
|
||
6. VERIFY: 풀 스위트+타입+린트+보안(+뮤테이션)
|
||
7. REFACTOR: 행위 불변
|
||
8. REVIEW: 인간이 **테스트 파일부터** 리뷰(74) → 지름길/삭제 탐지
|
||
9. DONE: 결정적 검사 통과 시에만 — 에이전트 "완료" 주장 불신 (63, 100)
|
||
```
|
||
|
||
이 긴 시나리오 단위가 곧 **하나의 리뷰 가능한 PR/커밋 크기**가 되도록 태스크를 나눈다. (참고: 한 발 단계의 PR 크기 근거로 쓸 만한 SOURCES 항목은 없음 — 운영 규약으로 결정)
|
||
|
||
---
|
||
|
||
## 긴 시나리오 체크리스트 (완성 게이트)
|
||
|
||
- [ ] 시나리오가 **사용자 가치**를 한 문장으로 담는다
|
||
- [ ] 정상 경로 + 경계 + 오류 + 상태전이 + 인가/보안이 매트릭스에 있다 (53, 89)
|
||
- [ ] `Then`이 관찰 가능한 결과만 단정 (44)
|
||
- [ ] 모든 행위가 추적 ID로 연결된다 (90)
|
||
- [ ] 각 RED가 '의미 있는 RED' 5축 충족 (02)
|
||
- [ ] 보호 수용 테스트가 보호 경로에 있고 에이전트가 수정 못 한다 (92, 05 §2)
|
||
- [ ] 최저 충분 계층에서만 검증, E2E는 임계 여정만 (57)
|
||
- [ ] 결함 발견 시 하위 계층 회귀 추가 (20)
|