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