상태 전이 테스트

상태 전이 테스트는 시스템의 응답이 현재 입력뿐 아니라 이전에 일어난 일에 따라 달라질 때 적용합니다. 시스템을 상태의 집합, 상태 간 전이를 일으키는 이벤트, 그리고 각 전이에 붙는 액션이나 가드 조건으로 모델링합니다. 그런 다음 유효한 전이를 테스트로 커버하고, 그만큼 중요하게 유효하지 않은 전이가 거부되는지도 확인합니다.

예시: 로그인 잠금

계정은 비밀번호를 연속으로 세 번 틀리면 잠기고, 로그인에 성공하면 실패 횟수가 초기화됩니다.

상태: Active (0 failures), 1 failure, 2 failures, Locked, Logged in.

현재 상태	이벤트	다음 상태
Active (0)	잘못된 비밀번호	1 failure
Active (0)	올바른 비밀번호	Logged in
1 failure	잘못된 비밀번호	2 failures
1 failure	올바른 비밀번호	Logged in (횟수 초기화)
2 failures	잘못된 비밀번호	Locked
2 failures	올바른 비밀번호	Logged in (횟수 초기화)
Locked	올바른 비밀번호	Locked (거부)
Locked	관리자 잠금 해제	Active (0)

여기서 도출한 테스트는 다음과 같습니다.

1. 모든 유효한 전이를 최소 한 번씩 실행합니다(0-스위치 커버리지). 틀림, 틀림, 틀림이면 Locked가 되고, 틀림, 맞음이면 Logged in이 됩니다.
2. 유효하지 않거나 예상치 못한 이벤트: 잠긴 계정에 올바른 비밀번호를 입력해도 반드시 거부되어야 합니다. 보안 버그가 숨어 있는 곳이 바로 여기입니다.
3. 시퀀스: 틀림, 맞음, 로그아웃 후 다시 틀림, 틀림을 실행합니다. 횟수가 정말 초기화되었는지, 아니면 두 번째 실패에서 계정이 잠기는지 확인합니다. 연속된 두 전이의 쌍을 테스트하는 것을 1-스위치 커버리지라고 합니다.

적용 분야

라이프사이클이 있는 것이라면 무엇이든 해당합니다. 주문(생성, 결제, 배송, 배송 완료, 취소, 환불), 버그 워크플로, 구독, 문서 결재, 결제 상태, 미디어 플레이어, UI 마법사 등입니다. 각 상태마다 다음을 질문해 볼 가치가 있습니다. 이 상태에서 허용되는 이벤트는 무엇인지, 허용되지 않는 이벤트는 어떻게 처리되는지, 그리고 브라우저 뒤로 가기 버튼이나 API 직접 호출처럼 예상치 못한 경로로 사용자가 이 상태에 도달할 수 있는지입니다.

흔한 실수

• 정상 경로(happy path)만 테스트합니다. 생성, 결제, 배송은 하나의 경로일 뿐입니다. 배송 후에 주문을 취소할 수 있는지, 두 번 환불될 수 있는지도 확인해야 합니다.
• UI로만 테스트합니다. UI에서는 취소 버튼이 숨겨져 있어도 API는 여전히 요청을 받아들일 수 있습니다. 전이는 API 레벨에서도 테스트합니다.
• 상태 테이블을 만들지 않습니다. 다이어그램은 일어나야 할 일을 보여 줄 뿐입니다. 모든 상태와 모든 이벤트를 교차한 전체 테이블을 만들어야 동작이 정의되지 않은 빈틈이 드러납니다.