---
title: ApprovalTests — 공식 사이트 (snapshot testing)
source_type: official-doc
url: https://approvaltests.com/
archive_url:
status: raw
confidence: high
related_branches: [feature-contract-verification-test-suite]
related_projects: [ca-skeleton]
tags: [contract-test, snapshot, approvaltests, verification, ca-skeleton, official-doc]
created: 2026-05-25
last_reviewed: 2026-05-27
---

# ApprovalTests — 공식 사이트 (snapshot testing)

> Layer: `raw/official-docs/` — approvaltests.com 발췌. ca-tmpl 이 contract test 도구로 **`approvaltests-java` JSON 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 proposition
  - `AT-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:
  - [[raw/branch-notes/feature-contract-verification-test-suite]]
- 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: (미작성)