답변.

부정적인 시나리오의 자동화는 완전한 테스트 시스템의 필수 부분입니다. 이는 시스템이 잘못된 행동, 잘못된 데이터, 서비스 중단 및 기타 비정상 상황에 대한 저항력을 검증하는 테스트입니다.

질문의 배경:

이전에는 긍정적인 시나리오(happy paths)에 주목하면서, 이 시나리오들은 자동화 및 유지 보수가 용이하기 때문이었습니다. 그러나 품질 요구 사항이 증가함에 따라, 버그는 주로 임계점에서 발생하며, 오류가 있거나 모호하게 잘못된 조건에서도 발생합니다. 이러한 수동 테스트는 빠르게 구식이 되며, 자동화는 성능 저하를 추적하는 데 도움이 됩니다.

문제:

모든 가능한 부정적인 시나리오 정의 및 커버리지
오류 메시지의 정확한 검증, 작업 실패 후 시스템 상태의 유효성 검증
비즈니스 로직 변경에 따른 테스트 유지 관리

해결책:

부정적인 시나리오를 식별하고 체계화 (Boundary Value Analysis, Equivalence Partitioning)
오류 메시지, HTTP 코드, 예외를 검증하기 위한 사용자 정의 assert 및 검증기 사용
부정적인 테스트 후 시스템 상태의 자동 "정리"

주요 특징:

명시적 테스트 배치: 오류, 예외, 비표준 입력 데이터에 대한 테스트
오류 메시지 및 시스템 내부 상태 검증
부작용 제어: 부정적인 테스트 후 시스템은 일관된 상태를 유지해야 합니다.

함정 질문.

부정적인 테스트에서 어떤 오류가 반환되는지만 확인하면 충분한가요?

아니요. 오류의 내용뿐만 아니라, 오류 발생 후 시스템 상태가 변하지 않았는지 확인하는 것도 중요합니다 (예: 잘못된 항목이 DB에 추가되지 않도록).

모든 가능한 부정적인 시나리오를 자동화해야 하나요?

아니요. 이들은 무한히 많을 수 있으며, 가장 가능성이 높고 중요한 것(Boundary Value, Null/Empty, 잘못된 유형, SQL 주입 등)을 구분하고, 나머지는 버그가 발생하는 대로 처리해야 합니다.

모든 부정적인 케이스에 대해 동일한 처리를 사용할 수 있나요?

아니요. 각기 다른 부정적인 시나리오는 각각의 검증, 예외 처리 및 롤백을 필요로 하며, 템플릿 assert는 충분하지 않습니다.

전형적인 오류 및 안티 패턴

부정적인 시나리오를 무시하거나 "형식적으로" 커버하기
설득력이 떨어지는 오류 검증(예: 코드 500만 확인하고 텍스트나 부작용 확인 안 함)
테스트 실패 후 정리되지 않은 테스트 환경

실제 사례

부정적 케이스

시스템은 유효한 등록 시나리오만 테스트하고 있습니다. 빈 이메일로 등록하는 것은 자동으로 검토되지 않습니다. 따라서, 빈 이메일로 사용자를 등록할 수 있는 문제가 발생하면 실전에서만 발견됩니다.

장점:

테스트 유지 관리가 용이
적은 수의 자동 테스트와 빠른 실행

단점:

심각한 버그가 실전에서 발견됨
수정 및 롤백 비용 증가

긍정적 케이스

각 부정적 시나리오(이메일 없음, 잘못된 형식, sql 주입)에 대해 새 계정 없음과 오류 메시지의 내용을 명시적으로 확인하는 자동화된 테스트가 있습니다.