계층별 테스트 전략

[Uechann]

본인 만의 계층별 테스트 전략에 대해서 서술해주세요.

[koreaioi]

최근, "이 테스트 코드는 무엇을 보호하는가?"를 생각해보려고 노력하고 있습니다.
추가로 제가 작성한 코드의 "어떤 점이 두렵기 때문에, 테스트 코드를 작성하려고 하는가?" 도 생각해보려고 합니다.

1. Domain

변해서 안되는 도메인 규칙과 이 도메인의 역할과 책임을 보호하기 위해 테스트 코드를 작성합니다.
도메인은 단위테스트로 매우 촘촘하게 진행해야 서비스 테스트가 비즈니스 흐름에 집중할 수 있다고 생각합니다.

• 서비스에 작성되어있는 검증 로직을, 관찰하고, 비슷한 관심사끼리 하나의 도메인으로 묶습니다. 그리고 이를 보호하기 위한 단위 테스트를 추가로 작성하려합니다.
• Fixture를 통해, 중복되는 객체 생성 코드를 간소화하려고합니다.

2. Service

통합 테스트는 비즈니스 시나리오(흐름)를 보호합니다. 도메인과 저장소 같은 여러 객체가 협력할 때, 그 조합과 순서가 올바른 지 검증합니다.
분기, 판단 로직이 많으면 바로 단위 테스트를 적기 보다는 비슷한 관심사의 도메인으로 묶어서, 처리할 수 있는 지 고민합니다. 그러나 외부 API가 있는 경우는 모킹하여 처리합니다.

• Support를 별도로 만들어, Service 마다 중복되는 코드를 제거하려고 노력합니다.

3. Repository

단순한 CRUD는 서비스 통합테스트로 처리합니다. (단순한 CRUD 테스트는 가치가 낮다고 판단)
다만, 복잡한 쿼리 로직이 존재한다면, 이 쿼리가 정상적으로 동작함을 보호하기 위해, 슬라이스 테스트를 작성합니다.

Repository를 모두 서비스 통합 테스트로 퉁치지 않는 이유

1. 서비스와 레포지토리를 테스트하는 이유가 근본적으로 다르다. (계층의 역할과 책임)
2. 복잡한 쿼리 로직의 예외상황, 경계를 모두 고려한 테스트 코드를 Repository에 작성하는 게 비용이 더 적다.

4. Controller

주로 인수 테스트를 진행합니다. 사용자와 약속된 시나리오를 보호하기 위한 목적입니다.
단위 테스트에서는 주로 Dto 검증을 수행하는데, 이는 Spring의 구현 책임이라고 생각이 들어, 테스트 코드가 보호하는 목적이 희미하다고 생각합니다.

• 인수 시나리오 가독성을 위해, 헬퍼 메서드를 사용합니다.

[softmoca]

저는 "계층별 테스트 전략"이라는 질문 자체를 다시 보고 싶습니다.

계층(Controller / Service / Repository / Domain)을 먼저 두고 "이 계층은 어떻게 테스트할까"를 묻는 사고는, 사실 도구에서 출발해 상황을 매칭하는 사고입니다.

네오의 피드백을 참고해, 저는 사고 방향을 거꾸로 잡았습니다 — "이 계층은 어떻게 깨질 수 있나"를 먼저 묻고, 그 깨짐을 가장 싸게 잡는 자리로 도구를 역산하는 방식입니다.

그래서 제 전략은 "Controller는 슬라이스, Service는 통합, Repository는 슬라이스, Domain은 단위"라는 정적 매칭표가 아니라, 계층마다 회귀가 어떻게 드러나는지를 분석하고 거기서 도구를 골라낸 결과입니다.

1. 출발점 — 계층이 아니라 "깨짐"에서 시작한다

이번 사이클을 거치며 가장 크게 바뀐 게 사고 방향입니다.

예전 방식 (매칭표 사고)

"Service는 통합 테스트가 적합하다 → 그러니까 모든 Service에 통합 테스트를 짠다"

지금 방식 (보호 대상 역산)

1. 이 계층은 어떻게 깨질 수 있나? (구체적 회귀 시나리오)
2. 그 깨짐이 어디서 드러나나? (객체 호출 / 실제 SQL / HTTP 통과)
3. 그 자리에서 가장 싸게 잡는 도구는?
4. 그 도구로 못 잡는 회귀는?

이 절차의 핵심은 같은 계층이라도 깨짐의 종류에 따라 도구가 갈린다는 점입니다.

Service의 분기 로직 회귀와 Service의 DB 협력 회귀는 같은 Service여도 다른 자리에서 잡힙니다.

그래서 "계층별 전략"이라는 말은 사실 단일한 답을 가질 수 없고, 계층 안에서도 회귀 종류별로 다시 갈라야 합니다.

2. Domain 계층 — 단위 테스트의 1순위 자리

여기서 잡히는 회귀

• 비즈니스 규칙의 부등호·경계값 실수 (< vs <=)
• 불변식 깨짐 (이름 30자, null 금지)
• 시간/상태 전이 규칙

도구 — 순수 단위 테스트

외부 의존성 없이 객체만 new로 만들어 검증합니다. Clock 같은 시간 의존성은 주입받아 고정합니다.

@Test
void 과거_시점_예약은_거부된다() {
    Clock fixed = Clock.fixed(...);
    assertThatThrownBy(() -> new Reservation("moca", pastDateTime, theme, fixed))
            .isInstanceOf(IllegalArgumentException.class);
}

왜 이 자리인가

• 회귀가 객체 호출만으로 드러난다 → DB·HTTP가 불필요
• 가장 싸다 (5ms)
• 분기·경계 조건을 많이 다룰 수 있다

미션에서의 적용

FutureOnlyPolicyTest가 정확히 이 자리의 사례였습니다.

기존엔 풀 컨텍스트 + 실제 H2 + insertTime까지 깔던 시간 의존 규칙을, 고정 Clock 주입만으로 검증하도록 내렸습니다.

분당 수십 배 빨라졌고 의도가 더 또렷해졌습니다.

WaitingsTest도 마찬가지입니다.

순번 계산 규칙은 외부 상태 없이 입력만으로 결정되므로, 가장 두꺼운 검증을 여기에 두었습니다.

의도적으로 안 하는 것

• Mock으로 의존성을 대체한 도메인 테스트 → 도메인은 의존성 자체가 적어야 한다. 의존성이 많아 Mock이 필요해진다면 그건 도메인이 빈약하다는 신호다.

3. Repository 계층 — 슬라이스 테스트가 유일하게 답하는 자리

여기서 잡히는 회귀

• SQL 문법 오타, 컬럼명 오타
• 파라미터 바인딩 순서 실수
• ORDER BY 누락, GROUP BY 실수
• 매핑 실수 (LocalDate ↔ DATE)
• 경계 조건 (빈 결과, 정렬, 필터링)

도구 — @JdbcTest(또는 @DataJpaTest) 슬라이스 + 실제 H2

@JdbcTest
class JdbcWaitingRepositoryTest {
    @Test
    void 같은_슬롯의_대기는_생성순으로_정렬되어_조회된다() {
        // 일부러 순서를 뒤섞어 insert
        insert("핀", 3번째시각);
        insert("콘", 1번째시각);
        insert("모카", 2번째시각);
        
        List<Waiting> result = repository.findBySlot(slot);
        
        assertThat(result).extracting(Waiting::name)
                .containsExactly("콘", "모카", "핀");
    }
}

왜 이 자리인가

• ORDER BY 누락 같은 회귀는 SQL을 실제 실행해야만 드러난다 → Mock으로는 못 잡고, 도메인 단위로도 못 잡는다
• 같은 회귀를 통합 테스트로도 잡을 수 있지만, 슬라이스가 훨씬 싸다 (300ms vs 3s)
• 케이스별 경계 조건을 여러 개 보기에도 슬라이스가 적합하다

미션에서의 적용

JdbcWaitingRepositoryTest의 ORDER BY 뒤섞기 테스트가 이 자리의 대표 사례였습니다.

"ORDER BY를 빠뜨리는 변경"이라는 회귀 시나리오를 명시하고, 깨지면 정렬이 잘못됐다는 사실이 바로 드러나도록 설계했습니다.

의도적으로 안 하는 것

• save의 해피 패스 두꺼운 검증 → 통합·인수 테스트가 자연히 거쳐 가므로 중복
• 프레임워크 기본 메서드(JpaRepository의 findById 등) 검증 → 우리 코드가 아니다

언제 비울 수 있는가

• Repository가 단순 위임이고 우리가 작성한 SQL이 없다면 → 이 자리는 비운다. Service 통합이 거쳐 가는 것으로 충분.

4. Service 계층 — 가장 신중하게 도구를 골라야 하는 자리

Service가 까다로운 이유는 하나의 Service 안에 여러 종류의 회귀가 섞여 있기 때문입니다.

그래서 저는 Service를 한 덩어리로 보지 않고, 회귀 종류별로 도구를 다르게 씁니다.

(a) DB 상태에 의존하는 비즈니스 규칙 → 통합 테스트

"같은 슬롯에 중복 예약 거부", "예약 취소 시 첫 대기 승격" 같은 규칙은 시스템 상태를 알아야 판정 가능합니다.

이런 회귀는 진짜 DB와의 협력에서만 드러납니다.

@SpringBootTest
class ReservationServiceIntegrationTest {
    @Test
    void 중복_예약은_거부된다() {
        helper.insertReservation(date, timeId, themeId);
        
        assertThatThrownBy(() -> service.create(date, timeId, themeId))
                .isInstanceOf(BusinessRuleViolationException.class);
    }
}

여기서 Mock을 쓰면 안 됩니다.

Mock으로 existsBySlot()이 true를 돌려주게 하는 순간, 정작 검증하려던 "중복의 정의(SQL의 WHERE 절)"가 우회됩니다.

사이클1 토론 규칙 3의 "Mock 금지 조항"이 정확히 이 자리에서 발동합니다.

(b) 단순 분기 로직 → Mock이 자리 있을 수 있다

"예약이 있으면 시간 삭제 거부" 같은 로직은 Repository의 boolean 응답이 곧 Service 분기의 입력입니다.

검증 대상이 SQL이 아니라 "true가 오면 예외, false면 진행"이라는 자바 if문이라면, Mock으로 충분합니다.

다만 이 자리도 Repository 슬라이스 테스트가 그 boolean을 진짜로 보장한다는 전제가 있어야 합니다.

Mock이 거짓말하지 않는다는 증거가 어딘가에 있어야 합니다.

(c) 트랜잭션 경계 → 통합 테스트가 유일한 답

@Transactional로 묶인 여러 작업의 원자성은 Mock으로 검증할 수 없습니다.

@Transactional은 Spring AOP 프록시가 동작해야 의미가 있는데, new로 만든 Service에서는 어노테이션이 그냥 무시됩니다.

@SpringBootTest  // @Transactional 없음 — 롤백이 트랜잭션 경계를 가려버리면 안 되므로
class ReservationCancelIntegrationTest {
    @Test
    void 예약_취소_중_대기_승격이_실패하면_취소도_롤백된다() {
        // 중간 실패 상황 재현 후, 예약과 대기 양쪽 상태 확인
    }
}

여기서 테스트에 @Transactional을 붙이지 않는 이유는 사이클1 격리 토론에서 정리한 함정입니다 — 테스트 롤백이 Service의 트랜잭션 경계를 가려버리면 검증 대상이 사라집니다.

의도적으로 안 하는 것

• Mock으로 의존성 모두 대체한 Service 단위 테스트 → "호출 순서가 맞았는가"만 검증하게 되어 리팩터링 내성이 약하다 (Mock 토론 결론)
• 같은 비즈니스 규칙을 통합과 단위 양쪽에서 검증 → 같은 보호를 두 번 사지 않는다

5. Controller 계층 — HTTP 어댑터로서의 책임만

여기서 잡히는 회귀

• @JsonFormat 누락으로 응답 형식이 깨짐
• @Valid 누락으로 잘못된 입력이 통과
• @RestControllerAdvice가 예외를 401·404·400으로 잘 변환하는가
• @ResponseStatus(CREATED)가 201을 반환하는가
• 인증/인가 인터셉터가 동작하는가

저는 Controller의 본질을 HTTP 어댑터로 봅니다.

그래서 검증 대상은 "HTTP 경계에서의 동작"이고, 이건 HTTP를 통과해야만 잡힙니다.

도구 — 인수 테스트 (RestAssured + @SpringBootTest)

@Test
void 잘못된_날짜_형식은_400을_반환한다() {
    RestAssured.given()
            .body("{\"date\":\"invalid\"}")
            .when().post("/reservations")
            .then().statusCode(400);
}

왜 슬라이스(@WebMvcTest)가 아닌가

@WebMvcTest로 Controller를 테스트하면서 Service를 Mock으로 대체하면, 결국 검증하는 것은 "내가 Mock을 설정한 대로 동작하는가"입니다.

진짜 유스케이스가 동작하는지는 알 수 없습니다.

저는 Controller를 통과하는 HTTP 동작(직렬화, Validation, 예외 변환)은 이미 인수 테스트가 자연히 거쳐 가므로, @WebMvcTest를 추가로 만들 가치가 낮다고 봅니다.

같은 보호를 두 번 사는 셈입니다.

예외 — Controller가 단순 위임을 넘어 분기/조립을 시작하면

페이징 파라미터 해석, 여러 Service 호출 조립, 응답 변환에 분기가 들어가면 더 이상 단순 위임이 아니라 테스트 대상으로 승격합니다.

그때는 @WebMvcTest를 고려할 수 있습니다.

의도적으로 안 하는 것

• 단순 위임 컨트롤러 별도 테스트 → Service·인수 테스트가 이미 검증한다
• 프레임워크 기능 자체 검증 (@Valid가 빈 문자열을 거부하는 동작) → Spring 책임이지 우리 책임이 아니다

6. 인수 테스트 — 시나리오 단위로 최소한만

여기서 잡히는 회귀

• 핵심 사용자 시나리오의 끝-끝 인과관계 (예약하면 가능 시간에서 빠진다)
• HTTP 계약(URL, 상태 코드, 응답 형식)의 회귀
• 여러 API 간 상태 전이가 의도대로 일어나는가

도구 — RestAssured + @SpringBootTest + 실제 H2

@Test
void 사용자_예약_정상_흐름() {
    // 1) 가능 시간 조회 → 1개
    // 2) 예약 생성
    // 3) 같은 조회 → 0개 (예약된 시간 빠짐)
    // 4) 같은 시간 다른 테마 → 여전히 1개
}

왜 이 자리인가

이건 어느 한 메서드를 검증하는 게 아니라 인과관계를 검증합니다.

"예약을 했기 때문에 다음 조회에서 빠진다"라는 두 호출 사이의 상태 전이가 검증 대상이지, 단일 메서드가 아닙니다.

이건 단위로도 슬라이스로도 못 잡습니다.

의도적으로 안 하는 것

• 모든 케이스를 인수 테스트로 만들기 → 너무 느리고 무겁다. 핵심 시나리오만.
• 단위 테스트로 검증 가능한 분기 케이스 반복 → 같은 보호를 두 번 사는 셈

7. 계층 간 중복 방지 — 같은 보호를 두 번 사지 않는다

저는 이게 계층별 전략의 가장 어려운 부분이라고 생각합니다.

각 계층에서 검증하기 좋아 보이는 회귀가 실제로는 다른 계층과 겹치는 경우가 많습니다.

겹침 사례 1

findAvailable 필터링 로직을 Repository 슬라이스(JdbcReservationTimeRepositoryTest)와 Service 통합(ReservationTimeServiceTest) 양쪽에서 검증하면 → 같은 SQL 동작을 두 번 사는 것.

슬라이스에 한 번만 두고, Service 통합은 비웁니다.

겹침 사례 2

"중복 예약 거부"라는 비즈니스 규칙이 Service 통합과 인수 테스트 양쪽에서 잡힌다면 → 인수 테스트는 정상 흐름의 인과관계만 보고, 거부 케이스는 Service 통합에 둡니다.

판단 기준

"같은 회귀가 두 자리에서 잡힌다 → 더 싼 자리에 두고 다른 자리는 비운다. 다른 자리가 추가로 사는 건 다른 회귀여야 한다."

이게 사이클1 피드백에서 "조건 3: 같은 보호를 두 번 사지 않는다"의 의미입니다.

8. 매트릭스로 요약

지금까지의 전략을 한 표로 요약하면 다음과 같습니다.

다만 이 표는 출발점이 아니라 결과입니다.

매번 보호 대상 역산 4단계를 거쳐 도달한 결과이고, 보호 대상이 바뀌면 칸도 바뀝니다.

계층	회귀 종류	도구	자주 비우는 칸
Domain	비즈니스 규칙, 불변식	순수 단위	의존성 많은 도메인 (그건 도메인이 빈약하다는 신호)
Repository	SQL, 매핑, 경계 조건	@jdbcTest 슬라이스 + H2	단순 위임 Repository, save 해피 패스
Service (DB 협력)	상태 의존 비즈니스 규칙	@SpringBootTest 통합	Mock 기반 단위 (호출 순서 검증화)
Service (분기)	boolean 응답에 대한 분기	Mock + Repository 슬라이스 보장	Repository가 단순할 때는 통합으로 흡수
Service (트랜잭션)	원자성, 롤백	@SpringBootTest (테스트 @transactional 없이)	Mock 단위 (구조적으로 불가능)
Controller	HTTP 어댑터 동작	인수 테스트(RestAssured)	단순 위임 Controller, @WebMvcTest 슬라이스
인수	핵심 시나리오, 인과관계	RestAssured + 실제 H2	단위로 잡히는 케이스 반복

중요한 함의

이 표의 모든 칸을 채워야 한다고 보지 않습니다.

사이클1 네오 피드백에서 받아들인 것처럼, 토론조마다 다른 패턴이 나오는 게 정상입니다.

비즈니스 규칙이 풍부한 도메인이면 도메인 단위가 두꺼워지고, CRUD 중심이면 통합이 두꺼워집니다.

어느 칸을 비웠다면 **"왜 비웠는지"**를 설명할 수 있어야 합니다.

9. 도메인 성격에 따라 비율이 달라진다

저는 "계층별 비율을 미리 정해두고 그에 맞춰 채우는" 사고를 피합니다.

비율은 결과이지 목표가 아닙니다.

도메인이 풍부한 경우

체스 같은 게임, 복잡한 정책

• 도메인 단위 테스트 비중이 크다
• 비즈니스 규칙이 객체 안에 응집되어 있어 외부 의존 없이 검증 가능

CRUD 중심인 경우

이번 미션처럼 도메인 규칙이 얇고 DB 상태 변화가 많음

• 통합 테스트 비중이 크다
• 검증의 핵심이 "실제로 DB에 저장되고 조회되는가"라서 단위로는 못 잡는다
• 테스트 피라미드의 "단위 많이 / 통합 적게" 권장에 무조건 맞추려 하면 오히려 신뢰가 떨어진다

이번 예약 대기 미션은 후자입니다.

그래서 통합 테스트 비중을 의도적으로 키웠고, 그게 도메인 성격에 맞는 자연스러운 비율이라고 생각합니다.

10. 정리

계층별 테스트 전략의 본질은 "각 계층에 어떤 도구를 매칭할 것인가"가 아니라, "각 계층이 어떻게 깨질 수 있고 그 깨짐을 가장 싸게 잡는 자리는 어디인가"이다.

핵심 원칙들

• 출발점은 계층이 아니라 회귀 시나리오다. 보호 대상에서 도구를 역산한다
• Domain은 단위 테스트의 1순위 자리 — 외부 의존 없는 규칙을 가장 싸게 잡는다
• Repository는 슬라이스 + 실제 H2 — 우리가 작성한 SQL이 있을 때만. 프레임워크 위임은 비운다
• Service는 회귀 종류별로 나눠본다 — DB 협력은 통합, 단순 분기는 Mock 가능, 트랜잭션은 통합이 유일
• Controller는 인수 테스트가 대체 — 단순 위임 Controller에 별도 슬라이스는 중복
• 인수 테스트는 핵심 시나리오만 — 인과관계가 검증 대상일 때
• 같은 보호를 두 번 사지 않는다 — 더 싼 자리에서 한 번, 다른 자리는 다른 회귀를 잡아야 의미가 있다
• 비율은 도메인 성격이 결정한다 — 미리 정해두고 채우는 게 아니다

그리고 무엇보다, 이 전략은 정적인 매뉴얼이 아니라 매번 새로 적용하는 사고 절차입니다.

새로운 기능을 만들 때마다 "이게 어떻게 깨질 수 있나"부터 묻고, 거기서 도구를 골라냅니다.

매트릭스의 칸이 채워지는 건 그 결과이고, 비어 있는 칸은 "일부러 비운 것 — 이유는 X"로 설명되어야 한다고 생각합니다.

[sangjun121]

어떤 테스트를 사용할 지를 결정하는 것은 결국, 어떤 코드와 범위를 검증할지에 따라 달라지기에, 결국 테스트의 목적에 따라 결정해야한다고 생각합니다. 핵심 기준은 이와 같지만, 각 계층별 특징을 통해 일반적으로 제가 사용하는 테스트 방식을 아래 작성해보았습니다! (테스트의 분류 기준에 대한 제 생각은 해당 글에 담았습니다. 이를 기반으로 아래 내용을 작성하였습니다.)

하지만, 더 실용적인 기준은 테스트 또한 유지보수의 영역이기 때문에, 테스트로 얻을 수 있는 신뢰가 유지 비용보다 더 큰가도 고민해볼 필요가 있다고 생각합니다.

Controller 요청 진입점

요청이 들어오고 나가는 Controller의 핵심 책임은 요청 값을 어플리케이션이 이해할 수 있도록 해석하는 것(객체로 변환하는 것)과 응답을 올바른 포멧으로 클라이이언트에게 전달해주는 것이라고 생각합니다.

따라서 저는 Controller에서는 요청/응답값 자체가 올바르게 파싱되는지에 대한 단위 테스트와 http와 웹 서버 단계의 연결이 올바르게 되는지와 같은 슬라이스테스트도 필요하다고 생각합니다.

Service 유스케이스 검증

서비스 계층은 유스케이스를 책임지는 계층으로, 비즈니스 흐름이 올바르게 작성되었는지 검증해야 합니다. 특히 서비스 계층은 유스케이스에 맞게, 정합성이 유지되어야 하는 한 단위의 트랜잭션이 표현되는 계층이기도 합니다. 따라서, 트랜잭션이 올바르게 작동하는지 슬라이스 테스트나 데이터베이스 연결을 통해 정합성이 유지되는지와 같은 통합테스트도 필요합니다.

또한 Service 내부에서 던져지는 예외에 대한 단위테스트 검증도 유용할 수 있다고 생각합니다. 하지만 너무 많은 테스트는 유지보수 비용이 발생할 수 있다는 생각이 들어, 단순 예외가 잘 던저지는지에 대한 검증은 Controller와의 통합테스트로 대체할 수 있다고도 생각합니다.

Repository DB 연결 검증

레포지토리는 DB와 연결되는 레이어로 보통 SQL이 올바르게 작동하는지, DB와 어플리케이션이 올바르게 매핑되는지에 대한 슬라이스 테스트, 통합테스트가 필요하다고 생각합니다. 그리고 단순 SQL문이 작동하는지 인메모리DB에 붙여 진행하는 테스트도 진행할 수 있겠지만, 실제 운영 데이터베이스와 스펙이나 엔진이 다른 경우 불안한 테스트가 될 수 있고, 유지보수 비용 또한 증가할 수 있다고 보아 작성을 지양합니다.

Domain 검증

핵심 로직이 담기는 계층으로 가장 우선적으로 검증되어야 하는 영역입니다. 외부 컴포넌트의 의존성 없이도 올바르게 비즈니스 규칙을 준수하는지 테스트하기 위해 핵심기능에 대한 단위테스트가 반드시 필요하다고 생각합니다. 그리고 계층별 테스트 작성단계는 좁은 범위의 도메인 검증부터 시작해서 넓은 범위인 컨트롤러 그리고 통합, 인수테스트순으로 작성되야 한다고 생각합니다.