다양한 테스트 유형을 프로젝트에 맞는 합리적인 전략으로 결합하는 방법을 알아보세요.
다시 방문해 주셔서 감사합니다. 마지막 도움말에서는 다양한 테스트 유형에 접근하는 방법과 각 테스트 유형에 포함된 항목에 관한 많은 기초를 다루었으며 테스트 유형의 정의를 명확히 했습니다. 이 작은 밈 이미지를 기억하시나요? 지금까지 배운 모든 테스트 유형이 어떻게 함께 작동할 수 있는지 궁금했을 것입니다.
이제 이 내용에 관해 자세히 알아보겠습니다. 이 도움말에서는 이러한 테스트 유형을 합리적인 전략으로 결합하고 프로젝트에 적합한 전략을 선택하는 방법을 소개합니다.
이 전략을 여러 모양과 비교하여 의미를 더 잘 파악할 수 있습니다. 다음은 크기 및 개발 범위에 해당하는 전략의 목록입니다.
전략을 자세히 살펴보고 이름 뒤에 숨겨진 의미를 알아보겠습니다.
테스트 목표 결정: 테스트를 통해 달성하고자 하는 것은 무엇인가요?
좋은 전략을 수립하기 전에 테스트 목표를 파악해야 합니다. 애플리케이션이 충분히 테스트되었다고 생각하는 시점은 언제입니까?
테스트에서 높은 테스트 범위를 달성하는 것이 개발자의 궁극적인 목표로 여겨지는 경우가 많습니다. 하지만 항상 최선의 접근 방식일까요? 테스트 전략을 결정할 때 사용자의 요구 사항을 충족하는 또 다른 중요한 요소가 있을 수 있습니다.
개발자는 다른 많은 애플리케이션과 기기도 사용합니다. 이러한 면에서 여러분은 이러한 모든 시스템을 '정상적으로 작동'하게 하는 사용자입니다. 따라서 애플리케이션과 기기가 작동하도록 최선을 다하는 수많은 개발자에게 의존하게 됩니다. 이런 상황을 되돌린다면, 개발자 여러분도 이러한 신뢰를 지키기 위해 노력해야 합니다. 따라서 첫 번째 목표는 항상 실제로 작동하는 소프트웨어를 출시하고 사용자에게 서비스를 제공하는 것입니다. 이는 애플리케이션 품질을 보장하기 위해 작성하는 테스트에도 적용됩니다. 켄트 C. Dodds는 그의 프런트엔드 앱을 위한 정적 테스트, 단위, 통합, E2E 테스트 게시물에서 이를 잘 설명하고 있습니다.
테스트가 소프트웨어 사용 방식과 유사할수록 더 큰 자신감을 얻을 수 있습니다.
개발자: Kent C. Dodds
켄트는 이를 테스트를 통해 자신감을 얻었다고 설명합니다. 적합한 테스트 유형을 선택하여 사용자와 더 가까워질수록 테스트 결과가 유효하다고 신뢰할 수 있습니다. 다시 말해, 피라미드를 오르는 높이로 올라갈수록 자신감이 높아집니다. 하지만 잠깐, 피라미드가 뭐야?
테스트 전략 결정: 테스트 전략을 선택하는 방법
첫 번째 단계로, 요구사항을 충족하는지 확인하기 위해 요구사항에서 확인해야 할 부분을 결정합니다. 효율적인 비용 구조를 유지하면서 가장 확신을 가질 수 있는 테스트 유형과 세부정보 수준을 알아보세요. 많은 개발자가 비유를 사용하여 이 주제에 접근합니다. 잘 알려진 고전 명작부터 시작해서 가장 많이 쓰이는 곡은 다음과 같습니다.
고전: 테스트 피라미드
테스트 전략을 세우기 시작하면 바로 첫 번째 비유인 테스트 자동화 피라미드를 보게 될 것입니다. Mike Cohn은 자신의 저서 'Succeeding with Agile'에서 이 개념을 소개했습니다. 나중에 Martin Fowler가 자신의 실질적 테스트 피라미드 문서에서 이 개념을 확장했습니다. 피라미드를 다음과 같이 시각적으로 나타낼 수 있습니다.
이 그림과 같이 테스트 피라미드는 세 개의 레이어로 구성됩니다.
단위. 이러한 테스트는 실행 속도가 빠르고 유지관리가 간단하기 때문에 피라미드의 기본 레이어에서 찾을 수 있습니다. 격리되어 있으며 대부분의 소규모 테스트 단위를 타겟팅합니다. 예를 들어 매우 작은 제품의 일반적인 단위 테스트를 참조하세요.
통합. 이러한 테스트는 실행 속도가 허용되지만 단위 테스트보다 사용자에게 더 가까이 다가갈 수 있기 때문에 피라미드 중간에 있습니다. 통합 테스트의 예로는 API 테스트가 있습니다. 구성요소 테스트도 이 유형으로 분류할 수 있습니다.
E2E 테스트 (UI 테스트라고도 함) 이 테스트는 실제 사용자와 사용자의 상호작용을 시뮬레이션합니다. 이러한 테스트는 실행하는 데 더 많은 시간이 필요하므로 비용이 더 많이 듭니다. 피라미드 정상에 있습니다.
신뢰도와 리소스 비교
앞에서 간략히 살펴본 것처럼 레이어의 순서는 우연이 아닙니다. 우선순위와 그에 따른 비용이 표시됩니다. 이렇게 하면 각 레이어에 작성해야 하는 테스트 수를 명확하게 파악할 수 있습니다. 테스트 유형의 정의에서 이미 확인했습니다.
E2E 테스트는 사용자와 가장 가깝기 때문에 애플리케이션이 의도한 대로 작동하는지 확인할 수 있습니다. 그러나 완전한 애플리케이션 스택과 시뮬레이션된 사용자가 필요하므로 가장 큰 비용이 들 수 있습니다. 따라서 자신감은 테스트를 실행하는 데 필요한 리소스와 직접적인 경쟁을 하게 됩니다.
피라미드는 개발자가 단위 테스트에 집중하고 E2E 테스트가 적용되는 사례의 우선순위를 엄격하게 지정하도록 하여 이 문제를 해결하려고 합니다. 예를 들어 가장 중요한 사용자 여정 또는 결함에 가장 취약한 장소를 파악할 수 있습니다. Martin Fowler가 강조했듯이 콘의 피라미드에서 가장 중요한 두 가지 핵심은 다음과 같습니다.
- 다양한 세부사항으로 테스트를 작성합니다.
- 높은 수준을 받을수록 테스트가 더 적게 필요합니다.
피라미드가 진화했다! 테스트 피라미드의 조정
수년 동안 피라미드를 중심으로 논의가 진행되었습니다. 이 피라미드는 테스트 전략을 지나치게 단순화하고 많은 테스트 유형을 제외하며 더 이상 모든 실제 프로젝트에 적합하지 않은 것으로 보입니다. 오해의 소지가 있을 수 있습니다. 피라미드의 형태가 사라졌나요? 기예르모 라우치는 이에 대해 다음과 같이 말합니다.
테스트를 작성합니다. 너무 많지 않습니다. 대부분 통합입니다.
길예르모 라우치 작성
이 주제는 이 주제에 관해 가장 일반적으로 인용되는 인용문 중 하나이므로 자세히 살펴보겠습니다.
- '테스트 작성'. 신뢰를 쌓을 뿐만 아니라 유지보수 시간을 절약해주기 때문입니다.
- '너무 많지 않음' 100% 적용 범위가 항상 좋은 것은 아닙니다. 테스트의 우선순위가 지정되지 않고 많은 유지관리가 필요하기 때문입니다.
- '대부분의 통합'. 여기서도 통합 테스트에 중점을 둡니다. 통합 테스트는 합리적인 실행 시간을 유지하면서 매일 높은 신뢰도 수준을 제공하여 가장 높은 비즈니스 가치를 실현합니다.
이를 통해 테스트 피라미드에 대해 다시 생각하고 통합 테스트에 집중할 수 있습니다. 지난 몇 년 동안 수많은 조정 모델이 제안되었으며 가장 일반적인 조정 방법을 살펴보겠습니다.
테스트 다이아몬드
첫 번째 조정은 테스트 피라미드에서 볼 수 있듯이 단위 테스트에 대한 과도한 강조를 없애줍니다. 단위 테스트의 100% 적용 범위에 도달했다고 가정해 보겠습니다. 그러나 다음에 리팩터링할 때 이러한 단위 테스트의 대부분을 업데이트해야 하므로 건너뛰고 싶을 수도 있습니다. 그래서 침식됩니다.
결과적으로 통합 테스트에 더 중점을 두면서 다음과 같은 형태가 발생할 수 있습니다.
피라미드가 다이아몬드로 진화합니다. 앞서 살펴본 3개의 레이어는 크기가 다르지만 단위 레이어가 잘린 것을 볼 수 있습니다.
- 단위. 이전에 정의한 방식으로 단위 테스트를 작성합니다. 그러나 보안 침해는 약화되고 우선 순위를 정하며 가장 중요한 사례만 커버하는 경향이 있기 때문에
- 통합. 알고 있는 통합 테스트로 단일 단위의 조합을 테스트합니다.
- E2E 이 레이어는 테스트 피라미드와 유사한 UI 테스트를 처리합니다. 가장 중요한 테스트 사례에 대해서만 E2E 테스트를 작성해야 합니다.
Honeycomb 테스트
Spotify에서 도입한 또 다른 조정 버전은 테스트 다이아몬드와 비슷하지만 마이크로서비스 기반 소프트웨어 시스템에 더 특화되어 있습니다. 테스트용 Honeycomb은 마이크로서비스 기반 소프트웨어 시스템을 위해 작성할 테스트의 세부사항, 범위, 개수를 시각적으로 비유한 것입니다. 마이크로서비스에서 가장 큰 복잡성은 크기가 작기 때문에 서비스 자체가 아니라 다른 사람과 상호작용하는 방식에 있습니다. 따라서 마이크로서비스 테스트 전략은 주로 통합 테스트에 중점을 두어야 합니다.
이 모양은 벌집을 연상시키는데, 이름인 셈입니다. 다음과 같은 레이어가 있습니다.
- 통합 테스트. Spotify의 기사에서는 J. B. Rainsberger는 '다른 시스템의 정확성에 따라 통과 또는 실패하는 테스트'라는 레이어를 정의합니다. 이러한 테스트에는 고려해야 할 외부 종속 항목이 있으며, 이와 반대로 시스템은 다른 시스템을 손상시키는 종속 항목일 수 있습니다. 다른 유사의 E2E 테스트와 마찬가지로 가장 중요한 사례에만 신중하게 이러한 테스트를 사용하세요.
- 통합 테스트. 다른 조정과 마찬가지로 이 레이어에 집중해야 합니다. 여기에는 보다 격리된 방식으로, 다른 서비스와 함께 서비스의 정확성을 확인하는 테스트가 포함되어 있습니다. 즉, 테스트에는 일부 다른 시스템도 포함되며 API 테스트 등을 통해 상호작용 지점에 중점을 둡니다.
- 구현 세부정보 테스트 이러한 테스트는 단위 테스트와 유사합니다. 이 테스트는 자연스럽게 격리되어 자체적인 내부 복잡성을 갖는 코드 부분에 중점을 둡니다.
이 테스트 전략에 관해 자세히 알아보려면 마틴 파울러의 테스트 피라미드와 벌집을 비교하는 게시물 및 Spotify의 원본 기사를 참조하세요.
테스트 트로피
통합 테스트에 초점을 맞추고 있는 것을 이미 확인할 수 있습니다. 그러나 이전 도움말에서 접한 또 다른 유형은 이론적 테스트가 아닌 테스트 전략에서 고려해야 할 중요한 측면입니다. 정적 분석은 테스트 피라미드와 지금까지 살펴본 대부분의 조정에서 누락되어 있습니다. 통합 테스트에 초점을 맞추면서 정적 분석을 고려하는 테스트 트로피 적응이 있습니다. 테스트 트로피는 기예르모 라우치의 초기 인용문에서 만들어졌으며 켄트 C. 도즈:
테스트 트로피는 테스트의 세분화 정도를 약간 다른 방식으로 묘사한 것과 유사합니다. 여기에는 4가지 레이어가 있습니다.
- 정적 분석. 이는 이 비유에서 중요한 역할을 하며 이미 설명한 디버깅 단계를 실행하기만 하면 오타, 스타일 실수 및 기타 버그를 포착할 수 있습니다.
- 단위 테스트. 최소 단위가 적절하게 테스트되도록 해 주지만 테스트 트로피는 테스트 피라미드와 동일한 정도를 강조하지 않습니다.
- 통합. 다른 조정과 마찬가지로 최적의 방법으로 비용과 높은 신뢰도 사이의 균형을 맞추므로 이 부분에 중점을 둡니다.
- UI 테스트. E2E 및 시각적 테스트를 포함해 테스트 트로피 상단에 위치하며 테스트 피라미드에서의 역할과 비슷합니다.
테스트 트로피에 대한 자세한 내용은 Kent C. Dodds에게 이러한 소식을 전해 드립니다.
UI에 중점을 둔 접근 방식
모두 잘 되어 있지만 광고 전략을 어떻게 '피라미드', '벌집' 또는 '다이아몬드'로 부르든 간에 여전히 놓칠 수 있는 것이 있습니다. 테스트 자동화도 중요하지만 수동 테스트는 여전히 필수적이라는 점을 기억해야 합니다. 자동화된 테스트를 통해 일상적인 작업을 줄이고 품질 보증 엔지니어가 중요한 영역에 집중할 수 있습니다. 수동 테스트를 대체하는 대신 자동화가 이를 보완해야 합니다. 최적의 결과를 위해 수동 테스트와 자동화를 통합할 수 있는 방법이 있나요?
아이스콘 테스트 및 게 테스트
실제로 UI에 중점을 둔 테스트 방법에 중점을 둔 테스트 피라미드의 두 가지 조정 버전이 있습니다. 둘 다 신뢰도가 높다는 이점이 있지만, 테스트 실행 속도가 느리기 때문에 당연히 비용이 더 많이 듭니다.
첫 번째는 테스트용 아이스콘으로, 피라미드가 뒤집힌 모양입니다. 수동 테스트 단계가 없으면 테스트 피자라고도 합니다.
아이스콘은 수동 또는 UI 테스트에 더 중점을 두며 단위 테스트는 가장 덜 집중합니다. 개발자들이 테스트 전략에 대해 몇 가지 생각만 가지고 작업을 시작한 프로젝트에서는 체계가 구축되곤 합니다. 아이스 코드는 피해야 할 패턴으로 여겨지고 당연합니다. 리소스 및 수동 작업 측면에서 비용이 많이 듭니다.
시험게는 시험용 아이스콘과 비슷하지만 E2E 및 시각적 테스트에 더 중점을 둡니다.
이 테스트 전략에는 애플리케이션이 정상적으로 작동하는지 확인하는 측면이 하나 더 포함됩니다. 테스트 게는 이전 도움말에 정의된 시각적 테스트의 중요성을 강조합니다. 구성요소 테스트와 API 테스트로 나뉘는 통합 테스트는 백그라운드로 나아가며, 단위 테스트는 여기에서 훨씬 더 부수적인 역할을 합니다. 이 테스트 전략에 관한 자세한 내용은 테스트 게에 관한 도움말을 참고하세요.
이 두 가지 테스트 전략은 비용이 많이 들긴 하지만 그 역할을 맡을 수 있습니다. 예를 들어 테스트를 필요로 하는 테스트가 적거나 복잡성이 적은 소규모 프로젝트에서 이를 고려해야 합니다. 이 경우 통합 테스트에 중점을 둔 본격적인 테스트 전략이 과잉 엔지니어링될 수 있습니다.
이 두 가지 테스트 전략은 비용이 더 많이 들 수 있지만, 예를 들어 테스트 횟수가 적고 복잡성도 많지 않은 소규모 프로젝트에서 사용할 수 있습니다. 이 경우 통합 테스트에 중점을 둔 전체 규모의 테스트 전략은 불필요하게 복잡할 수 있습니다.
실용적인 조언: 전략을 세워 보세요.
지금까지 가장 일반적인 테스트 전략에 대해 알아보았습니다. 고전 '테스트 피라미드'로 시작해서 여러 버전의 피라미드에 대해 알게 되었습니다. 이제 제품에 대해 평가한 다음 프로젝트에 가장 적합한 것을 결정해야 합니다. 이 질문에 대한 답변은 모두가 선호하는 '경우에 따라 다름'으로 시작해야 합니다. 그렇다고 해서 정확도가 낮아지는 것은 아닙니다.
위에서 설명한 테스트 전략 중에서 가장 적절한 테스트 전략과 빠진 테스트 전략 중에서 선택하는 것은 애플리케이션에 따라 다릅니다. 아키텍처, 요구사항, 사용자 및 사용자의 요구사항을 반영해야 합니다. 이 모든 것은 애플리케이션마다 다를 수 있습니다. 이는 지극히 정상입니다. 가장 중요한 목표는 교과서의 정의가 아니라 사용자에게 서비스를 제공하는 것입니다.
실제 테스트를 개별적으로 분리하여 정의하기 어려운 경우가 많습니다. 마틴 파울러도 단위 테스트의 경우와 같이 정의가 다른 긍정적인 측면을 강조합니다. 저스틴 설스가 그의 트윗에서 올바르게 언급한 내용은 다음과 같습니다.
[...] 명확한 경계를 설정하고, 빠르고 안정적으로 실행되며, 유용한 이유로만 실패하는 생생한 테스트를 작성할 수 있습니다.
제공: Justin Searls
사용자가 겪을 수 있는 실제 오류를 보고하고 목표에 방해가 되지 않는 테스트에 집중하세요. 테스트는 사용자에게 도움이 되도록 설계되어야 합니다. 100% 커버리지를 제공하거나 작성할 테스트 유형의 비율을 논의하기 위한 것이 아닙니다.
사용자가 겪을 수 있고 목표 달성을 방해하지 않는 실제 오류를 보고하는 테스트에 집중하세요. 테스트는 사용자에게 도움이 되도록 설계되어야 합니다. 100% 커버리지를 제공하거나 특정 테스트 유형의 몇 퍼센트를 작성해야 하는지에 대한 논쟁을 불러일으킬 수 있어야 합니다.