테스트

본 문서는 무엇을 어떤 방식으로 검증하는지, 그리고 구조 규칙을 강제하는 수단을 정의합니다.

1. 대상과 방식

단위 테스트는 복잡도와 도메인 중요도가 모두 높은 코드에 집중합니다. 조회 서비스는 로직이 거의 없는 매핑 코드라 회귀 방지 효과가 낮고, 정작 검증해야 할 SQL과 스키마의 정합성은 가짜 객체로 잡히지 않습니다.

조회 서비스라도 단순 매핑이 아니라 판단을 포함하면 단위 테스트를 씁니다. 접근 범위를 요청이 아니라 인증된 신원에서 얻는지 여부가 그 예이며, 가짜 구현으로 고정 검증이 가능합니다.

공유 개발 데이터베이스를 쓰지 않습니다. 상태가 누적되어 어제의 데이터가 오늘의 검증을 통과시키며, 실패가 재현되지 않습니다. 통합 테스트는 IntegrationTestSupport 를 상속해 Testcontainers 가 띄운 1회용 PostgreSQL 컨테이너를 공유합니다.

2. 분리가 값을 갖는지 검증합니다

계층 3절이 도메인과 영속 모델의 분리에 두 조건을 걸었습니다. 두 조건이 실제로 유지되는지를 테스트가 확인합니다.

두 번째는 테스트를 쓰는 것만으로 자동 확인됩니다. 컨텍스트를 요구하기 시작하면 그 시점에 조건이 깨진 것이므로 별도 감시가 필요 없습니다.

3. 이름

테스트 이름은 실행 가능한 명세입니다. 이름 목록만 훑어도 그 컨텍스트의 업무 규칙이 파악되어야 합니다.

메서드명에 한국어를 허용합니다. 컨벤션 검사기의 명명 규칙을 config/checkstyle/suppressions.xml 에서 테스트 소스에 한해 완화하며 프로덕션 코드는 그대로 둡니다. 완화는 메서드명에만 적용하고 지역변수와 파라미터, 그리고 가짜 구현 클래스의 필드까지 프로덕션과 같은 규칙을 따릅니다. 완화의 근거가 "이름이 곧 명세 문장"인데 변수와 필드는 그 대상이 아니기 때문입니다. 완화 범위를 넓게 짐작하고 쓰면 빌드가 check 단계에서 멈추므로 테스트만 돌려 본 상태로는 드러나지 않습니다.

한국어 메서드명을 {@link #메서드()} 로 참조하면 Javadoc 파서가 깨지므로 {@code 메서드()} 를 씁니다.

4. 메커니즘을 봐야 하는 경우

동시성과 잠금처럼 창이 수 밀리초인 결함은 결과 관찰로 재현되지 않습니다.

그런 경우에는 결과가 아니라 메커니즘을 확인합니다. 테스트가 대상 행을 잠근 채 붙들고, 검증 대상 경로가 진행하지 못하는 것을 봅니다.

5. 구조 규칙의 강제

구조 규칙을 ArchUnit 테스트로 인코딩하고 빌드 게이트에 포함합니다. 위반은 빌드 실패입니다.

규칙 목록은 디커플드 아키텍처 11절이 원본이며, 규칙의 내용은 패키지 배치와 참조 규칙이 정의합니다.

규칙은 컨텍스트를 열거하지 않고 패키지에서 자동 판별합니다. 열거하면 컨텍스트를 추가할 때마다 테스트를 고쳐야 하고, 고치는 것을 잊으면 새 컨텍스트만 검사에서 빠집니다. 근거는 결정-0055입니다.

application 이 infrastructure 를 의존하지 않는다는 규칙이 조회 경로에도 그대로 적용되므로, 영속성 라이브러리를 application 에서 허용하는 예외 규칙을 두지 않습니다.