donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
docs/ca-skeleton-frontend-runtime-adapter-features
llm-wiki/raw/official-docs/verification-approvaltests-snapshot-official.md
T

7.0 KiB
Raw Permalink Blame History

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
feature-contract-verification-test-suite
ca-skeleton
contract-test
snapshot
approvaltests
verification
ca-skeleton
official-doc
2026-05-25 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 조사로 수집한 경우:

컨텍스트 / 왜 저장했는지

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 / 관련

Reference in New Issue View Git Blame Copy Permalink