테스트 피라미드

테스트 피라미드는 자동화 테스트를 레벨별로 어떻게 배분할지에 대한 지침입니다. 넓은 바닥은 빠르고 저렴하며 정확한 단위 테스트입니다. 가운데는 통합 테스트 또는 서비스 테스트입니다. 좁은 꼭대기는 UI를 통한 엔드투엔드 테스트로, 가장 현실적인 확신을 주지만 가장 느리고 깨지기 쉽습니다. Mike Cohn이 널리 알린 이 개념의 핵심은 각 검증을 문제를 잡아낼 수 있는 가장 낮은 레벨로 내려보내는 것입니다.

예시

“100달러를 넘는 주문은 무료 배송”이라는 규칙을 예로 들어 보겠습니다.

• 단위: 배송비 함수를 99.99달러, 100.00달러, 100.01달러로 테스트합니다. 각각 몇 밀리초면 끝나고 브라우저도 필요 없습니다.
• 통합/API: 120달러짜리 장바구니로 POST /orders를 호출하고 응답에 shipping: 0이 있는지 어설션합니다. 이것으로 규칙이 서비스에 제대로 연결되어 있음을 증명합니다.
• 엔드투엔드: 조건을 충족하는 장바구니로 결제를 진행하고 확인 페이지에서 “Free shipping”을 확인하는 UI 테스트 하나입니다.

경계값을 위해 UI 테스트를 10개나 만들 필요는 없습니다. 계산이 맞는지는 이미 단위 테스트가 증명합니다.

모양이 중요한 이유

상위 레벨의 테스트는 더 많은 컴포넌트를 거치므로, 실패했을 때 버그가 어디에 있는지 알려 주는 정보가 적습니다. 또 브라우저, 환경, 테스트 데이터가 필요해 더 느리고 불안정(flaky)해지기 쉽습니다. 대부분이 UI 테스트로 이루어진 스위트(“아이스크림 콘” 안티패턴)는 몇 시간씩 실행되고, 변경과 무관한 이유로 실패하며, 결국 무시당합니다.

비판과 대안

피라미드는 경험칙이지 할당량이 아닙니다. “테스팅 트로피(testing trophy)” 같은 대안은 통합 테스트에 더 큰 비중을 두며, 목을 과도하게 사용한 단위 테스트는 실제 시스템이 망가져 있어도 통과할 수 있다고 주장합니다. 두 모델 모두 중요한 점에는 동의합니다. 느리고 범위가 넓은 UI 테스트는 적게 유지하면서 핵심 사용자 여정에 집중하고, 확신의 대부분은 더 빠른 계층에서 얻으라는 것입니다. 균형은 고정된 비율이 아니라 실제로 버그가 어디서 발생하는지를 보고 정합니다.