donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
55de4f55b037af9554af9007ce834030ac7e729e
llm-wiki/raw/official-docs/test-taxonomy-testcontainers-official.md
T

8.0 KiB
Raw 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
Testcontainers — 공식 introduction official-doc https://testcontainers.com/guides/introducing-testcontainers/ raw high
feature-test-taxonomy-fixture-contract
ca-skeleton
testcontainers
integration-test
test-taxonomy
ca-skeleton
official-doc
2026-05-25 2026-05-27

Testcontainers — 공식 introduction

Layer: raw/official-docs/ — Testcontainers 공식 introduction guide 발췌. feature-test-taxonomy-fixture-contract 의 "integration test 부터 Testcontainers 강제" 결정의 1차 근거.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-test-taxonomy-fixture-contract "integration test 부터 Testcontainers 강제, unit/contract/architecture 는 금지" 분기 정책의 공식 근거 (real services vs in-memory)

특정 branch 없이 foundational 조사로 수집한 경우:

컨텍스트 / 왜 저장했는지

ca-tmpl 결정 중 "Testcontainers 는 integration test 부터 강제. unit/contract/architecture test 는 Testcontainers 금지" 는 테스트 단계 분리의 핵심 규칙 이다. 공식 입장이 이 규칙과 정합한지, 그리고 in-memory DB(H2 등) 대신 real container 를 쓰는 이유의 원문이 필요했다.

출처 / Source

핵심 인용 / Key quotes (verbatim)

[§What is Testcontainers?] "Testcontainers is a testing library that provides easy and lightweight APIs for bootstrapping integration tests with real services wrapped in Docker containers."

[§Opening paragraph] "the bulk of the application code might still be in integrating with those external services"

[§What is Testcontainers?] "you can write tests talking to the same type of services you use in production without mocks or in-memory services"

[§What problems does Testcontainers solve?] "You can run your integration tests right from your IDE, just like you run unit tests."

[§What problems does Testcontainers solve?] "In-memory services may not have all the features of your production service...you might be using advanced features of Postgres/Oracle databases in your application. But H2 might not support all those features"

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
TC-OFFICIAL-C1 Testcontainers 는 Docker container 로 감싼 real service 로 integration test 를 부트스트랩하는 가벼운 테스팅 라이브러리 [§What is Testcontainers?] "Testcontainers is a testing library that provides easy and lightweight APIs for bootstrapping integration tests with real services wrapped in Docker containers." official-vendor-doc Testcontainers 의 자체 정의 Testcontainers 가 unit test 에도 적합하다는 뜻은 아님 — "integration tests" 명시
TC-OFFICIAL-C2 애플리케이션 코드의 상당 부분이 외부 서비스와의 통합에 있음 (테스트 필요성의 배경) [§Opening paragraph] "the bulk of the application code might still be in integrating with those external services" official-vendor-doc integration test 의 필요성 정당화 모든 프로젝트에서 통합 코드가 다수라는 보편 사실 주장 아님 — Testcontainers 채택 정당화 맥락
TC-OFFICIAL-C3 mock / in-memory service 없이 production 과 동일한 type 의 서비스로 테스트 작성 가능 [§What is Testcontainers?] "you can write tests talking to the same type of services you use in production without mocks or in-memory services" official-vendor-doc real-dep integration test 도구 선택 "production 과 동일한 version" 까지 보장한다는 뜻은 아님 — "same type"
TC-OFFICIAL-C4 IDE 에서 unit test 처럼 integration test 를 직접 실행 가능 [§What problems does Testcontainers solve?] "You can run your integration tests right from your IDE, just like you run unit tests." official-vendor-doc 개발자 워크플로 (CI 없이 로컬 실행) unit test 와 동일한 실행 속도라는 주장은 아님 — 실행 가능성만
TC-OFFICIAL-C5 in-memory service 는 production service 의 모든 feature 를 갖지 않을 수 있음 (예: Postgres/Oracle 고급 기능을 H2 가 미지원) [§What problems does Testcontainers solve?] "In-memory services may not have all the features of your production service...you might be using advanced features of Postgres/Oracle databases in your application. But H2 might not support all those features" official-vendor-doc H2 등 in-memory DB 의 한계 인지 "H2 가 항상 모든 케이스에 부적합" 이라는 일반화는 아님 — 일부 기능 미지원만

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • TC-OFFICIAL-C1: Testcontainers 의 self-definition (real services, integration test 부트스트랩)
    • TC-OFFICIAL-C3: real-dep test 가 mock/in-memory 없이 가능하다는 공식 입장
    • TC-OFFICIAL-C4: IDE 에서 직접 실행 가능 (개발자 경험)
    • TC-OFFICIAL-C5: H2 같은 in-memory DB 가 production feature 모두를 보장 못 한다는 공식 입장
  • 이 자료가 증명하지 않는 것:
    • "5분 unit test budget" 같은 정량 기준 — 본 페이지는 시간 예산 명시 안 함
    • "unit/contract/architecture test 에서 Testcontainers 사용 금지" — 본 페이지는 integration 에 권장만, 다른 level 금지는 ca-tmpl 의 별도 결정
    • Testcontainers 가 모든 외부 서비스 (특정 IBM Mainframe 등) 를 지원한다는 보장
    • container start time 의 구체 비용
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • ca-tmpl unit budget (5분) 을 Testcontainers 가 깨뜨리는지 — 실제 측정 필요 (container start cost)
    • CI 환경 (GitHub Actions 등) 에서 Docker-in-Docker 정책 — 본 자료는 IDE 만 언급
    • testcontainers-java 의 JUnit 5 통합 + Spring Boot 통합의 구체 설정 (별도 가이드 페이지 필요)

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

  • 공식 입장 = "real services in Docker" (TC-OFFICIAL-C1, TC-OFFICIAL-C3). H2 같은 in-memory DB 는 SQL 방언 차이로 false-pass 를 만든다는 것이 핵심 논거 (TC-OFFICIAL-C5 가 직접 지지).
  • ca-tmpl 의 "unit/contract/architecture test 에서 Testcontainers 금지" 는 5분 budget 보호 결정과 정합하지만, 이 budget 자체는 본 자료가 증명하지 않음 — 별도 결정.
  • 따라서 5min budget 을 깨지 않으면서도 real-dep 신뢰도를 확보하는 분기 = "integration 부터" — 본 자료가 직접 부합하는 부분은 "real services for integration", "금지" 결정은 별도.

Related / 관련

Reference in New Issue View Git Blame Copy Permalink