7.0 KiB
7.0 KiB
title, source_type, url, archive_url, status, confidence, related_branches, related_projects, tags, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | related_branches | related_projects | tags | created | last_reviewed | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ApprovalTests — 공식 사이트 (snapshot testing) | official-doc | https://approvaltests.com/ | raw | high |
|
|
|
2026-05-25 | 2026-05-27 |
ApprovalTests — 공식 사이트 (snapshot testing)
Layer:
raw/official-docs/— approvaltests.com 발췌. ca-tmpl 이 contract test 도구로approvaltests-javaJSON snapshot test 를 명시 채택한 결정의 1차 근거.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-contract-verification-test-suite | "contract test 도구 = JSON snapshot test (approvaltests-java)" 채택 결정 — complex object 비교의 공식 패턴 근거 |
특정 branch 없이 foundational 조사로 수집한 경우:
- raw/project-notes/ca-skeleton-operational-contract — Test Contract (§12) 의 envelope/error shape 검증 baseline
컨텍스트 / 왜 저장했는지
feature-contract-verification-test-suite 의 ca-tmpl 결정 중 다음을 직접 인용한다:
"contract test 도구 = (1) envelope/error/log/env shape: JSON snapshot test (approvaltests-java 또는 자체 snapshot)"
approvaltests 의 철학 (snapshot/golden master) 이 운영 계약 (envelope/error/log shape) 검증에 적합한지 원문 근거 보존.
출처 / Source
- 원본 URL: https://approvaltests.com/
- 아카이브 URL: (미수집)
- 저자 / 조직: Approval Tests Library project (homepage 자체에는 individual author 표기 없음 — historically Llewellyn Falco 등)
- 발행일: 지속적으로 갱신
- 마지막 확인일: 2026-05-27
핵심 인용 / Key quotes (verbatim)
[§Homepage hero] "A picture's worth a 1000 tests."
[§Homepage introduction] "In normal unit testing, you say
assertEquals(5, person.getAge()). Approvals allow you to do this when the thing that you want to assert is no longer a primitive but a complex object. For example, you can say,Approvals.verify(person)."
[§Workflow step 6] "Approve result so it continues to work"
[§Workflow step 9] "Re-approve so it continues to work"
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| AT-OFFICIAL-C1 | ApprovalTests 의 슬로건 — snapshot 한 장이 수많은 assertion 을 대신함 | [§Homepage hero] "A picture's worth a 1000 tests." | official-vendor-doc |
snapshot testing 정당화 slogan | 1000:1 비율을 정량 보장한다는 뜻은 아님 — 마케팅적 표현 |
| AT-OFFICIAL-C2 | primitive 가 아닌 complex object 를 assert 할 때 Approvals.verify(person) 패턴이 assertEquals(5, person.getAge()) 대신 사용됨 |
[§Homepage introduction] "In normal unit testing, you say assertEquals(5, person.getAge()). Approvals allow you to do this when the thing that you want to assert is no longer a primitive but a complex object. For example, you can say, Approvals.verify(person)." |
official-vendor-doc |
complex object 비교용 contract test 도구 선택 | 모든 unit test 를 Approvals.verify 로 대체하라는 권고는 아님 — primitive 비교는 여전히 assertEquals 적합 |
| AT-OFFICIAL-C3 | 결과를 approve 함으로써 회귀 보호 — workflow step 6 (initial) + step 9 (re-approve on intentional change) | [§Workflow steps 6, 9] "Approve result so it continues to work" / "Re-approve so it continues to work" | official-vendor-doc |
snapshot 의 회귀 보호 메커니즘 (approve → diff fail 시 알림 → 재승인) | 자동화 도구 (CI 에서 자동 approve) 권고 아님 — 명시적 사람의 approve action 전제 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
AT-OFFICIAL-C1: snapshot 의 high-level value propositionAT-OFFICIAL-C2:Approvals.verify(<complex object>)패턴의 공식 권장 사용 시나리오AT-OFFICIAL-C3: approve/re-approve workflow (변경 시 명시적 재승인)
- 이 자료가 증명하지 않는 것:
- "envelope/error/log/env shape 검증에 적합" 이라는 ca-tmpl 의 적용 결정 — 본 자료는 일반 complex object 만 언급, "envelope/error" 같은 운영 계약 영역 직접 명시 없음
- JSON 형식의 snapshot 이 다른 형식 (XML/YAML/binary) 보다 우월하다는 주장
- Pact CDC 대비 우월성 — homepage 는 두 도구 비교 안 함
approvaltests-java의 Spring Boot 통합 / JUnit 5 구체 설정
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 "envelope/error/log/env shape" 4가지 사용처 각각에서 ApprovalTests 사용 패턴 검증 (별도 reference doc 필요)
- snapshot 파일 위치 정책 (
__snapshots__/등) 의 ca-tmpl 합의 - CI 에서 snapshot mismatch 시 fail 처리 (auto-approve 금지) 설정 —
AT-OFFICIAL-C3의 명시적 approve 원칙 보호
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
- envelope/error shape 는 field 개수가 많고 nested 이므로 individual
assertEquals보다 snapshot 이 유지보수상 우월 —AT-OFFICIAL-C2의 "complex object" 정의에 정합. - 단점: 무엇이 변했는지 snapshot diff 로만 보여줌. 그래서
approvaltests단독으로는 부족하고, 본 skeleton 은:- JSON snapshot = envelope/error shape (본 자료 적용)
- ArchUnit rule = boundary/capability (별도 자료)
- springdoc-openapi diff = API drift (별도)
- Logback ListAppender = log field shape (별도) 중첩하여 다층 보호.
- Pact CDC 대안과의 차이: snapshot 은 provider-side full schema 를, Pact 는 consumer-known subset 을 보호 — 본 자료가 직접 말하지 않는 비교, ca-tmpl 의 별도 분석.
- ca-tmpl 결정 = snapshot(=full schema) 이 single-team skeleton 에 적합 — 본 자료의 "complex object" 패턴이 envelope/error 시나리오에 맞다는 가정. 별도 검증 필요.
Related / 관련
- 같은 주제 다른 official-doc / 자료:
- raw/official-docs/verification-pact-cdc-official — consumer-driven 대안
- raw/official-docs/verification-spring-cloud-contract-official — Spring 생태계 CDC 대안
- raw/official-docs/test-taxonomy-practical-pyramid-fowler — CDC workflow 일반론
- raw/official-docs/test-taxonomy-testcontainers-official — integration level 와의 역할 분리
- 인용하는 branch:
- canonical contract 섹션:
- raw/project-notes/ca-skeleton-operational-contract (Test Contract §12)
- 대안 그룹: Group G-G — Skeleton Governance (verification)
- 본 source 의 위치: ca-tmpl 채택안 baseline — ApprovalTests JSON snapshot
- 인용하는 wiki: (미작성)