혹시 UI를 활용한 애플리케이션 테스트를 어떻게 부르시나요? E2E 테스트? 함수형 테스트? 시스템 테스트? 셀레니움 테스트? 정말 많은 이름들이 있습니다. 그렇다면 통합 테스트는 정확히 어떤 걸 의미하는 걸까요? 단위 테스트는요? 우리는 이 이름들을 어떻게 짓게 된 걸까요?
이름의 의미에 대해서 같은 생각을 가지고 팀을 설득하는 일은 쉽지 않습니다. 더군다나 다른 용어를 사용하는 팀이나 프로젝트 구성원들을 만나면 훨씬 더 힘들어지죠.
테스트 타입에 대해 이름을 짓는 것은 특정 프레이즈가 의미하는 것에 대한 공유하고 있는 이해에 기반합니다. 이 것때문에 굉장히 정의가 모호해지거나 혼란스러워지죠. 우리에겐 더 나은 방법이 필요합니다. 구글에서는 이런 문제를 어떻게 해결할까요?
구글러들은 정성적인 것보단 측정 가능한 데이터들, 즉 정량적인 것들에 기반해 결정하는 것을 선호합니다. 이런 정량적인 것들에 기반한 테스트 네이밍 컨벤션은 아래와 같습니다.
-
Small, Medium, Large
여기서 집중해야할 것은 각 테스트 유형의 장단점이 아닌 각 유형들이 특정 역할들을 각자 담당하고 있다는 것입니다. 세 가지 유형이 모든 유형의 테스트를 포함하진 않지만 프로젝트를 진행하며 필요한 대부분의 주요 테스트들은 확실히 포함하고 있습니다.
Small 은 단위 테스트와 완벽하게 동일하고 Large 는 E2E 혹은 시스템 테스트, Medium 은 애플리케이션 내부의 2개 티어가 제대로 협력하고 있는지를 확인하는 테스트(통합 테스트)와 동일합니다.
이렇게 테스트를 정의함으로써 얻는 주요 이점은 바로 아래 요소들을 통제하는 것입니다.
- 예를 들어 자바에서는 특정 테스트 크기로 설정되어 있고 특정 액션을 허용하지 않는 테스트 스위트에서 SecurityManager를 쉽게 설치할 수 있습니다.
- 테스트의 크기를 나타내기 위해서 간단한 어노테이션을 사용하기 때문에 특정 크기의 테스트들을 테스트 스위트로 모으는 것이 굉장히 간단해집니다.
- 만약 테스트가 어떤 순서로든 실행해할 수 있어야 한다는 요구사항이 존재한다면 우리는 테스트에 각 테스트들을 철저하게 격리해야 합니다. 이 때 다른 테스트가 사용할 수 있는 데이터를 남겨선 안됩니다.
- 꽤 불편할테지만 테스트들이 병렬적으로 실행 가능하도록 만드는 중요한 부분입니다. 결과적으로 테스트 스위트를 쉽게 구축하고 일관성을 보장한 채로 실행할 수 있습니다.