3.9 KiB
3.9 KiB
title, source_type, status, related_branches, related_projects, tags, created, status_label
| title | source_type | status | related_branches | related_projects | tags | created | status_label | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| interview-prep / archunit-manual-importer-vs-analyzeclasses | interview-prep | raw |
|
|
|
2026-06-19 | collecting |
interview-prep: archunit-manual-importer-vs-analyzeclasses
Layer:
raw/interviews/— 면접 질문 원본 수집·연구 노트. 다듬어진 답변은/interviewize후wiki/interview/에 별도 작성.
Parent / 부모
- raw/branch-notes/feature-test-taxonomy-fixture-contract — Task 2 에서 "contract·architecture 레벨 test 는 Testcontainers 의존 금지" rule 을 구현할 때 부딪힌 핵심 결정.
질문 / Question
- 질문 원문: ArchUnit 에서
@AnalyzeClasses(importOptions = DoNotIncludeTests.class)와new ClassFileImporter().importPackages(...)를 각각 언제 쓰나요? 규칙의 대상 이 test 코드 자체일 때 왜@AnalyzeClasses만으로는 안 되나요? - 출처: 예상 질문 (실 면접 아님).
- 받은 날짜·맥락: 아직 없음 — 2026-06-19 test-taxonomy-fixture-contract 구현에서 도출.
질문 의도 추론 / Why this question
- 핵심 평가 대상:
- ArchUnit 의 import scope 가 규칙이 무엇을 볼 수 있는가 를 결정한다는 것을 이해하는지. 규칙 본문(
noClasses().should()...)만 보고 "왜 안 잡히지?" 를 import 설정에서 진단할 수 있는지. - production 규칙과 test-에-대한 규칙을 한 suite 에 섞었을 때 생기는 vacuous-pass 위험을 인지하는지.
- ArchUnit 의 import scope 가 규칙이 무엇을 볼 수 있는가 를 결정한다는 것을 이해하는지. 규칙 본문(
답변 골자 / Answer skeleton (raw)
- ca-tmpl 의 production 아키텍처 suite(
CleanArchitectureTest,DisabledAdapterArchitectureTest,NamingConventionTest)는 전부@AnalyzeClasses(packages = "dev.caskeleton", importOptions = ImportOption.DoNotIncludeTests.class)— production bytecode 만 본다. 그래야 "domain 은 Spring 의존 금지" 같은 규칙이 test util 의 Spring import 때문에 오탐하지 않는다. - 그런데 test-taxonomy 계약(§테스트 계약 #4: "contract·architecture 테스트 가 Testcontainers 에 의존하면 실패")은 대상이 test 클래스 다.
DoNotIncludeTests가 그 클래스를 import 단계에서 제거하므로@AnalyzeClasses규칙은 영원히 빈 subject 를 받아 vacuously pass 한다. - 해법: 규칙을
static final ArchRule필드로 정의하고, 별도@Test에서new ClassFileImporter().importPackages("dev.caskeleton.bootstrap.contract")로 test bytecode 를 명시적으로 로드해rule.evaluate(corpus)를 직접 호출한다.ArchitectureViolationFixtureTest가 violation fixture 를 같은 방식으로 로드하는 패턴과 동일하다. importPackages는.class바이트를 직접 읽어 JVM class loading 을 하지 않으므로testCompileOnly타입(Testcontainers 등)이 runtime 에 resolve 되지 않아도 안전하다.- vacuity 방어: 규칙을 정의했으면 반드시 positive control 을 둔다 — 본 작업에서는 Testcontainers 를 실제로 쓰는
bootstrap.integration패키지에 같은 규칙을 평가해hasViolation() == true를 단언했다. (관련: raw/interviews/archunit-static-analysis-limits, raw/blog-topics/archunit-violations-as-data-pattern-2026-05-28)
더 팔 거리 / Follow-ups
allowEmptyShould(true)를 언제 쓰고 왜 위험한가 (빈 subject 를 의도적으로 허용 → positive control 없으면 vacuous). 관련 errors: raw/errors/archunit-empty-should-anchor-2026-05-27.- production 규칙(
production_code_does_not_depend_on_test_fixtures)은DoNotIncludeTests위에서 동작하는데 어떻게 meta-verify 했나 → fixtureleak violation 패키지를 manual importer 로 로드해 같은 rule 객체를 평가.