#4 - 테스트, 트랜잭션 경계

1. 테스트: 불신을 코드로 고정하는 방법

테스트는 기능을 증명하는 도구가 아니다.

테스트는 "믿지 않겠다는 약속"을 코드로 고정하는 장치다.

1.1 Controller 테스트는 얇아야 한다

Controller 테스트의 목적은 단 하나다.

잘못된 요청은 절대 안으로 들어오지 못한다

java

@WebMvcTest(OrderController.class)
class OrderControllerTest {

    @Test
    void 수량이_음수면_400을_반환한다() throws Exception {
        mockMvc.perform(post("/orders")
                .contentType(MediaType.APPLICATION_JSON)
                .content("{\"productId\":1, \"quantity\":-1}"))
            .andExpect(status().isBadRequest());
    }
}

👉 Controller 테스트는 신뢰 경계 테스트다.

10.2 Service 테스트는 규칙을 증명한다

Service 테스트에서는 "동작"이 아니라 "판단"을 검증한다.

java

@Test
void 재고가_없으면_주문할_수_없다() {
    assertThatThrownBy(() -> orderService.create(req))
        .isInstanceOf(BusinessException.class);
}

2. 트랜잭션 경계: 신뢰의 범위

트랜잭션은 DB 기술이 아니다.

트랜잭션은 "여기까지는 믿는다"는 선언이다.

21 트랜잭션은 Service에서 시작한다

Controller ❌
Entity ❌
Service ⭕

java

@Transactional
public void create(CreateOrderRequest req) {
    // 이 메서드 안에서만 상태 일관성을 보장한다
}

👉 트랜잭션 밖의 세계는 언제든 실패할 수 있다.

11.2 트랜잭션을 쪼개지 말아야 하는 이유

중간 실패
부분 저장
복구 불가능 상태

이 모든 것은 경계가 흐릿할 때 발생한다.

3. 비동기 처리: 믿지 않음을 전제로 한 설계

비동기는 성능을 위한 도구가 아니다.

비동기는 실패를 전제로 하는 구조다.

3.1 비동기로 넘기기 전에 반드시 끝내야 할 것

비즈니스 규칙 검증
상태 변경의 확정

java

orderRepository.save(order);
eventPublisher.publish(new OrderCreatedEvent(order.getId()));

👉 이벤트 이후의 세계는 다시 믿지 않는다.

32 비동기 영역에서 절대 하면 안 되는 것

핵심 상태 변경
트랜잭션 의존 로직

비동기는 "나중에 해도 되는 일"만 맡긴다.

4. 전문가 관점의 최종 정리

테스트는 불신을 고정한다
트랜잭션은 신뢰 범위를 자른다
비동기는 실패를 인정한다

이 세 가지가 합쳐질 때, Spring Boot는 단순한 프레임워크가 아니라 안전한 백엔드 플랫폼이 된다.

여기까지 이해했다면,
이제 Spring Boot 4를 "쓴다"가 아니라
"지배한다"고 말할 수 있다.

#4 - 테스트, 트랜잭션 경계

중년개발자

1. 테스트: 불신을 코드로 고정하는 방법

1.1 Controller 테스트는 얇아야 한다

10.2 Service 테스트는 규칙을 증명한다

2. 트랜잭션 경계: 신뢰의 범위

21 트랜잭션은 Service에서 시작한다

11.2 트랜잭션을 쪼개지 말아야 하는 이유

3. 비동기 처리: 믿지 않음을 전제로 한 설계

3.1 비동기로 넘기기 전에 반드시 끝내야 할 것

32 비동기 영역에서 절대 하면 안 되는 것

4. 전문가 관점의 최종 정리

목차

댓글 0