[번역]마틴파울러의 테스트 피라미드

원문 : https://martinfowler.com/bliki/TestPyramid.html

bliki: TestPyramid

 

테스트 피라미드는 자동화된 테스트를 어떻게 효율적으로 만들지 고민하기 위해 만들어진 형태입니다. 여기서 중요한 점은 고수준 테스트를 만들기 보다는 최대한 저수준의 유닛테스트를 많이 만들어야 한다는 점입니다.

 

자동화된 테스트는 대부분 유저 인터페이스를 통한 테스트를 뜻해 왔습니다. 만들어진 애플리케이션이 있다면 특정한 툴을 통해 애플리케이션과 연동하여 입력값을 저장했고 다시 입력값을 실행하는 형태로 진행해 왔습니다. 이런 접근 방식은 꽤 오래되었습니다. 테스트를 저장하기 쉬웠고 프로그래밍을 모르는 사람도 테스트를 만들 수 있었습니다.

 

그러나 이런 접근 방식의 테스트는 금방 문제를 일으켰고 아이스크림 콘이 되었습니다. UI를 통한 테스트는 느렸을 뿐만아니라 빌드 시간을 늘렸습니다. 가끔 테스트 자동화 소프트웨어를 사용하기 위해 라이센스를 설치해야 했으며 특정 머신에서만 돌릴 수 있다는 것을 뜻했습니다. 그리고 이런 테스트들은 headless 모드로 실행되기 어려웠으며 배포 파이프라인에 태우기 위해 스크립트들을 모니터링해야 했습니다.

 

무엇보다도 이런 테스트는 매우 취약합니다. 시스템이 발전됨에 따라 이런 테스트들은 깨지기 쉬웠고 테스트를 다시 녹화하여 저장해야만 합니다. 테스트 기록 플레이 백 툴을 사용한다면 이런 문제를 줄일 수 있겠지만, 점점더 테스트를 하기는 어려워졌습니다. 아무리 좋은 테스트를 짜더라도 엔드-투-엔드 테스트를 수행할 때 비결정론 테스트(때로는 실패하고 때로는 성공하는)가 발생하기 때문에 테스트를 신뢰 할 수 없었습니다. 짧게 말하자면, UI를 통한 테스트는 재작성해야할 가능성이 높고, 녹화하기 어렵고, 실행하는데 시간이 오래 걸립니다. 그렇기 때문에 전통적인 GUI 기반 테스트를 수행하기보다는 유닛 테스트의 자동화를 통해 피라미드 형태의 테스트를 구성해야 합니다.

 

피라미드형태의 테스트는 애플리케이션의 서비스 레이어 아래에서 테스트가 이루어집니다. 이것은 종전의 엔드-투-엔드 테스트에 비해 많은 장점을 가지고 있으며 UI 프레임워크처럼 복잡하지도 않습니다. 웹 애플리케이션을 예로 들자면 Selenium이나 Sahi와 같은 프레임워크를 사용하여 UI 테스트를 수행해야합니다.

 

테스트 피라미드는 애자일 테스팅 싸이클에서 많이 사용됩니다. 그리고 잘 만들어진 테스트 포트폴리오에서 자주 볼 수 있습니다. 테스트를 만들다 보면 엔드-투-엔드 테스트, UI 테스트, 사용자 테스트를 모두 통합하려는 문제가 팀에서 자주 보입니다. 이 테스트들은 통합될 수 없습니다. 예를 들어 Javascript UI는 Jasmine과 같은 도구를 통해 UI 동작 테스트를 하곤 합니다. 복잡한 비즈니스 규칙이 담긴 사용자가 보는 화면 테스트를 하기 보다는 해당 화면과 관계있는 모듈들을 유닛 테스트를 하는 편이 낫습니다.

 

항상 고수준 테스트를 수행할 때 두번째 라인 테스트가 있는 것을 확인할 수 있습니다. 만약 고레벨 테스트에서 실패가 난다면 기능 코드에서 버그를 찾을 것이 아니라 유닛 테스트에서 실패한 내용을 찾아야 할것입니다. 그렇기 때문에 고수준 테스트를 수행하여 버그를 잡기 전에 반드시 유닛 테스트에서 발생되는 버그를 잡아야합니다. 유닛 테스트는 버그들을 없앨 수 있는 확실한 방법이기 때문입니다.