Postman 테스트? NO! 테스트 코드를 활용하자!

0. 왜 굳이 테스트 코드를 써야 할까?

수동 postman	자동 테스트
사람이 눌러야 한다	머신이 대신 눌러 준다
한 번만 재현하면 끝	PR마다 반복
새 기능이 다른 코드 깨져도 모름	깨지면 파이프라인 즉시 실패

 

결국 “테스트 코드 = 내가 없어도 코드를 눌러 줄 Postman” 이다.

---

1. JUnit: 순수 메서드부터 테스트 하기!

class DiscountServiceTest { 

    @Test 
    void vip_고객은_10퍼센트_할인() { 
    DiscountService svc = new DiscountService(); 
    int price = svc.apply(1000, Grade.VIP); assertEquals(900, price); 
    } 
    
}

Why 이렇게 시작하나?

이유	설명
의존성 0	스프링 컨테이너 없이 새 객체만 만들면 끝
학습 곡선 완만	Mockito · MockMvc 같은 툴을 몰라도 바로 실행
실패 지점 명확	비즈니스 로직 한눈에 파악 → 디버깅이 쉽다

 

만약 서비스 로직을 순수 자바로 먼저 설계해 두면, 컨테이너를 띄우지 않아도 대부분의 로직을 검증할 수 있다.

 

2. 통합 테스트

앞에서 스프링 없이도 되는 걸 확인했다면, 이번엔 진짜 빈 주입 + DB 트랜잭션까지 시험해 보자

given when then 주석을 통해 구분해가며 하니까 확실히 편했다(인프런 김영한 강사님 강의를 보고 배웠다..ㅎㅎ)

@SpringBootTest
@Transactional
class OrderServiceIntegrationTest {

    @Autowired OrderService orderService;
    @Autowired OrderRepository orderRepository;

    @Test
    void 주문_생성_정상_동작() {
        // given
        OrderDto dto = new OrderDto(1L, List.of(3L, 4L));

        // when
        Long orderId = orderService.placeOrder(dto);

        // then
        Order saved = orderRepository.findById(orderId).orElseThrow();
        assertEquals(OrderStatus.PLACED, saved.getStatus());
    }
}

• @SpringBootTest : 실제 스프링 컨테이너 기동
• @Transactional : 테스트 후 롤백 → DB 깨끗

---

3. 후기

뭔가 테스트 코드라는 이름에 겁 먹었는데 시나리오를 짜는 느낌이라 신선하고 재밌었다.

물론 비즈니스 요구 사항을 구현하면서 이렇게 테스트 코드까지 생각하고 짜게 된다면 로직을 짜는데 소요되는 개발 시간이 꽤 늘어날 것 같아서 약간의 트레이드 오프는 있을 것 같다.

하지만 이를 통해서 휴먼 에러를 방지할 수 있다면 그 정도 시간 소요는 감수할만하지 않을까 하는 생각을 조심스레 해본다..!