init: llm-wiki-haness 하네스 설계
This commit is contained in:
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: Gradle sample-off test classpath isolation
|
||||
source_type: interview
|
||||
status: raw
|
||||
tags: [gradle, testing, clean-architecture, sample-fixture]
|
||||
created: 2026-06-25
|
||||
---
|
||||
|
||||
# Gradle sample-off test classpath isolation
|
||||
|
||||
## Parent
|
||||
|
||||
- [[raw/branch-notes/feature-sample-removal-adoption-contract]]
|
||||
|
||||
## Question
|
||||
|
||||
템플릿 저장소가 sample fixture 모듈을 유지해야 하지만 production/core 계약은 sample 없이도 검증되어야 한다. Gradle 멀티모듈에서 이를 어떻게 설계할 수 있는가?
|
||||
|
||||
## Expected answer
|
||||
|
||||
- sample module은 production dependency가 아니라 fixture/test dependency로 둔다.
|
||||
- 일반 `test`는 sample-on 축으로 유지한다.
|
||||
- 별도 `sampleOffTest` source set/task를 만들어 같은 core contract test source를 실행하되 `sample-portfolio` dependency를 classpath에서 제외한다.
|
||||
- sample을 직접 import하던 core test는 제거하거나 sample module 소유 테스트로 이동한다.
|
||||
- CI release gate에는 sample-on과 sample-off를 모두 포함한다.
|
||||
- ArchUnit 같은 bytecode 스캐너는 custom test output을 production output으로 오인하지 않도록 import option을 보강한다.
|
||||
|
||||
## Follow-up probes
|
||||
|
||||
- 왜 runtime profile이 아니라 build/test matrix인가?
|
||||
- Custom source set에서 dependency locking과 main output을 왜 별도로 확인해야 하는가?
|
||||
- sample 제거 후 빈 ArchUnit corpus는 실패로 볼지 정상으로 볼지 어떻게 결정하는가?
|
||||
- Hosted CI와 local verification의 증거 등급은 어떻게 구분하는가?
|
||||
Reference in New Issue
Block a user