🛒 Backend Engineering · 7/9 · 약 8분

Backend Engineering 시리즈 전체 보기

주문 완료 화면을 한 번 통과했다고 해서 주문 흐름이 안전하다고 말하기는 어렵다. 중복 요청, 늦은 사건, 시간 초과, 보상처럼 정상 경로 밖의 조건에서 상태와 부수 효과가 쉽게 어긋난다.

가상의 주문 상태 전이 표를 테스트의 출발점으로 삼아 보았다. 시나리오를 시작 상태, 사건, 기대 상태로 표현하자 테스트가 단순한 화면 통과 확인이 아니라 업무 규칙의 실행 가능한 설명이 되었다.

#Backend · #E2E · #Testing · #StateMachine

이 글에서 다룰 것

• 상태 전이 규칙을 E2E 시나리오로 바꾸는 방법
• 중복·순서 역전·시간 초과·보상 축을 다루는 기준
• 최종 상태와 부수 효과를 함께 검증하는 이유

상태 전이 표를 어떻게 테스트 문장으로 바꿀까

‘주문이 성공한다’는 시나리오는 시작 조건과 실패 지점을 설명하지 못한다. 대신 ‘처리 중 상태에서 완료 사건을 받으면 완료 상태가 되고 후속 알림이 한 번 생성된다’처럼 시작 상태, 사건, 기대 결과를 한 문장에 담는다. 테스트 이름만 읽어도 어떤 규칙을 보호하는지 알 수 있어야 한다.

허용된 전이만 테스트해서는 충분하지 않다. 이미 종료된 상태에 이전 사건이 도착하거나, 현재 상태에서 허용되지 않은 요청이 들어오는 경우도 상태 유지 또는 명시적 거절 시나리오로 만든다. 전이 표의 빈칸도 의도된 금지인지 누락인지 확인해야 한다.

기본 시나리오 형식은 다음처럼 정리할 수 있다.

준비 데이터
  + 시작 상태
  + 입력 사건
        ↓
기대 상태
  + 부수 효과 횟수
  + 사용자에게 보이는 결과
  + 남아야 할 사건 기록

이 형식을 사용하면 구현이 바뀌어도 테스트의 업무 의미는 유지된다.

정상 경로 밖에서 어떤 예외 축을 꺼내야 할까

각 전이에 중복, 순서 역전, 시간 초과, 보상이라는 네 가지 축을 대입해 적용 여부를 판단한다. 모든 조합을 무작정 늘리는 것이 아니라, 불변식이 달라지는 대표 조합을 선택한다. 예를 들어 같은 완료 사건의 반복은 상태 유지와 후속 알림 미발생을 확인하는 시나리오가 된다.

순서 역전 시나리오는 이미 종료된 상태에 과거 단계 사건을 넣고 상태가 뒤로 가지 않는지 본다. 시간 초과 시나리오는 다음 사건이 오지 않았을 때 예약한 정리 작업과 사용자 안내가 일치하는지 확인한다. 보상 시나리오는 일부 작업만 끝난 지점에서 재실행해 최종 상태가 안전한 결과로 수렴하는지 검증한다.