문제 상황
기능 구현이 끝났다고 해서, 정말로 로직이 정상적으로 동작한다고 확신할 수 있을까?
기능 구현 이후 Postman을 통해 API를 테스트하며
정상 동작 여부를 확인하고 있었다.
하지만 다음과 같은 한계를 느꼈다.
- 성공 케이스 위주의 검증만 가능
- 예외 상황을 체계적으로 확인하기 어려움
- 서비스 내부 로직 흐름까지 검증하기 어려움
- 동일한 조건으로 반복 테스트하기 어려움
특히 주문 생성과 같이
포인트 차감, 결제 처리, 이벤트 발행이 함께 이루어지는 로직은
단순 API 호출만으로는 정확한 동작을 확신하기 어려웠다.
문제 인식
단순히 "동작한다"는 것을 확인하는 것과
"정상적으로 설계된 대로 동작한다"는 것을 검증하는 것은 다르다고 느꼈다.
특히 비즈니스 로직이 포함된 서비스 레이어는
코드 수준에서의 검증이 필요하다고 판단했다.
해결 방향
서비스 레이어 전반에 대해 단위 테스트를 작성하여
비즈니스 로직을 직접 검증하기로 했다.
- MenuService
- OrderService
- OrderItemService
- PaymentService
- PointHistoryService
- UserService
테스트 코드 작성 방식
Mockito를 활용하여 Repository를 mocking하고
Service 로직을 독립적으로 검증했다.
verify(orderRepository, times(1)).save(any(Order.class));
verify(eventPublisher, times(1)).publishEvent(any(OrderCompletedEvent.class));
verify(paymentRepository, never()).save(any(Payment.class));
이를 통해 결과 값뿐 아니라
실제 로직 흐름까지 함께 검증할 수 있었다.
적용 결과
- 서비스 로직을 코드 수준에서 검증
- 예외 처리 로직 검증
- 이벤트 발행 여부 확인
- 불필요한 DB 호출 방지 검증
- 동일한 조건에서 반복 테스트 가능
느낀 점
Postman 기반 테스트만으로는
서비스 로직을 충분히 검증하기 어렵다는 것을 느꼈다.
테스트 코드를 작성하면서
비즈니스 로직을 "확인"이 아닌 "검증"하는 과정이 중요하다는 것을 체감했다.
앞으로는 기능 구현과 함께 테스트 코드 작성까지 함께 진행하는 습관을 가져야겠다고 생각했다 !!
'트러블슈팅' 카테고리의 다른 글
| 인덱스 B-Tree 이해 (성능이 빨라지는 이유) (0) | 2026.04.02 |
|---|---|
| 인덱스 적용 이후에도 느렸던 이유 - 캐싱 도입 (0) | 2026.04.02 |
| Request DTO에 @Builder를 쓰면 안 되는 이유 (0) | 2026.04.01 |
| 인기 메뉴 조회 성능 개선 - 인덱스 도입 (0) | 2026.04.01 |
| 포인트 차감 동시성 문제 해결 - 비관적 락 적용 (0) | 2026.04.01 |