단위 테스트.. 통합 테스트.. 인수테스트.. 그게 뭔데 💧
미션을 진행하며 특히 테스트
에 대해 깊게 생각해보는 경험을 갖게 되었습니다.
기존 프로젝트에선 TDD가 중요하대~
, TDD 개발해 본 경험이 우대된대~
정도만 안 상태로 큰 고려를 하지 못했는데, 막상 뛰어들어본 테스트의 세계는 생각보다 더 구조화 되어있었습니다.
이를 기반으로! 테스트 종류에 대해 정리하는 글을 작성하게 되었습니다.
테스트코드 성능 개선기 게시글, 단위 테스트vs통합 테스트vs인수 테스트게시글, 테스트 피라미드게시글,[번역]마틴 파울러의 테스트 피라미드게시글을 참조하였습니다!
도움이 되어주셔서 감사합니다🍀
마틴 파울러의 테스트 피라미드는 아래와 같습니다.
각 단계는 인수 테스트(UI) -> 통합 테스트 -> 단위 테스트 로 구성되는데,
직관적으로 파악할 수 있듯 밑으로 내려 올 수록 더 많은 테스트 코드를 작성하라는 뜻으로 알려져 있습니다. (상위 테스트일수록 비용이 높기 때문에!)
추상적이지만 가장 작은 단위로 기능을 나누어 그 기능을 테스트하는 기법입니다.
대상 단위의 크기는 엄격하게 정해져있지 않습니다. 하지만, 단위의 크기가 작을수록 복잡성이 낮아져서 테스트하기가 더 용이해집니다.
따라서, 테스트 대상 단위의 크기를 작게 설정해서 단위 테스트를 최대한 간단하고 디버깅하기 쉽게 작성해야 합니다.
(ex. 만든 함수의 input과 output을 검증)
개발자가 변경할 수 없는 부분 (ex. 외부 라이브러리) 까지 묶어서 검증할 때 사용합니다.
DB에 접근하거나, 다양한 환경이 제대로 작동하는지 확인하는데 필요한 모든 작업을 수행할 수 있습니다.
(ex. 내가 작성한 함수 뿐만이 아니라 다른 사람이 작성한 함수와 다른 함수, 그리고 라이브러리 등을 합쳐서 검증)
시나리오에 맞춰 수행하는 테스트입니다. 개발자가 직접 시나리오를 제작할 수도 있지만, 다른 의사소통 집단으로부터 시나리오를 받아(인수) 개발한다는 의미를 갖고 있습니다.
인수 테스트는 SW 인수를 목적으로 하는 테스트라고도 합니다. SW를 인수하기 전에, 명세한 요구사항대로 잘 작동하는지 검증하는 것입니다. SW의 내부 구조나 구현 방법을 고려하기 보단, 실제 사용자 관점에서 테스트하는 경우가 많습니다.
따라서 인수 테스트는 SW 내부 코드에 관심을 가지지 않는 블랙박스 테스트 입니다.
UI Test야말로 단위가 커서 한 번 실행하는데 비용이 많이 소모되기 때문에, 여러 UI Test가 생성되면 실행이 느려질 수 있습니다. 따라서 피라미드형으로 개수를 유지하는 것이 좋다는 것이 전반적으로 알려진 개념입니다.
하지만 모든 경우에 항상 피라미드형 테스트 비율을 유지할 수는 없습니다. 도메인의 특성에 따라 비율을 조정하는 것이 가장 옳은 방식입니다.