deploy-site / deploy (push) Failing after 40s

Details

docs: record the 1.1.0 release and add the infrastructure map

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.

2026-09-16 23:27:52 +09:00

5.1 KiB

Raw Permalink Blame History

04 · 긴 시나리오(Long Scenario)로 RED 재구성

목적: 무수한 미시(단위) RED를 "사용자가 겪는 긴 여정(장면)" 단위로 재구성한다. RED(테스트)는 단일 행위의 단일 테스트로 고정하되, 테스트를 긴 시나리오(행위 사양)에서 파생시킨다. 장면 단위를 "시나리오/행위 사양", 그에서 나온 테스트를 "미시 RED"로 용어 구분한다. 이로써 미시 RED 난립을 막고, 행위 완성도(traceability)와 에이전트 제어성을 동시에 얻는다.

왜 긴 시나리오인가

Beck(Canon TDD)의 1단계가 곧 긴 시나리오: "며칠 동안 안 쓰던 기능까지 전부(행위 변형 목록) 나열하라." 마이크로부터 시작하면 완성도를 놓친다.
Alderson(2026): 티켓마다 "구현 전에 테스트 계획(통상 사용 + 엣지 + 커버 방식)"을 논의 — 이것이 곧 시나리오 명세.
SDD(2026): 수용 시나리오 → 테스트 매트릭스 → Test ID → 파일(추적).
테스트 피라미드(56): 행위는 최저 충분 계층에서 검증 — 같은 시나리오를 전 계층에 중복 금지.
Shore: 수용은 "대화"가 본질 — 시나리오는 그 대화를 구조화한 산출물.

긴 시나리오 템플릿 (Gherkin 계열)

Feature: (사용자 가치를 하나의 문장으로)

  Scenario: (한 장면의 제목)
    Given <초기 상태 / 사전조건>
      And <추가 상태>
     When <행위/사건>
     Then <관찰 가능한 결과 1>
      And <관찰 가능한 결과 2>
      And <부수 효과/경계/오류 투명성>

좋은 예 (올바른 것을 만드는가 + 만드는 방법 모두 명세):

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)

5.1 KiB Raw Permalink Blame History Unescape Escape