테스트하거나 하지 않는 것의 기술적 관점

테스트해야 할 대상과 제외할 수 있는 대상을 결정합니다.

Ramona Schwering

이전 도움말에서는 테스트 사례의 기본사항과 테스트에 포함되어야 하는 사항을 알아보았습니다. 이 도움말에서는 기술적인 관점에서 테스트 사례를 만드는 과정을 자세히 살펴보고 각 테스트에 포함되어야 하는 사항과 피해야 할 사항을 자세히 설명합니다. 기본적으로 '테스트할 사항' 또는 '테스트하지 말아야 할 사항'과 같은 오랜 질문의 답을 배울 수 있습니다.

테스트할 항목 또는 테스트하지 않아야 할 항목.

일반 가이드라인 및 패턴

단위 테스트, 통합 테스트, 엔드 투 엔드 테스트 중 무엇을 실행하든 특정 패턴과 포인트가 매우 중요하다는 점에 유의해야 합니다. 이 원칙은 두 가지 유형의 테스트에 모두 적용될 수 있으며, 적용되어야 하므로, 좋은 출발점입니다.

간결하게 만들기

테스트를 작성할 때 기억해야 할 가장 중요한 사항 중 하나는 단순성을 유지하는 것입니다. 뇌의 능력을 고려하는 것이 중요합니다. 기본 프로덕션 코드는 상당한 공간을 차지하므로 추가적인 복잡성을 위한 여지는 거의 없습니다. 테스트의 경우 특히 그렇습니다.

사용 가능한 헤드 공간이 부족하면 테스트에 집중할 수 있습니다. 따라서 테스트에 단순성을 우선시하는 것이 중요합니다. 실제로 Yoni Goldberg의 JavaScript 테스트 권장사항은 황금률의 중요성을 강조합니다. 테스트는 복잡한 수학 공식이 아니라 어시스턴트처럼 느껴져야 합니다. 즉, 테스트의 의도를 한눈에 이해할 수 있어야 합니다.

테스트를 복잡하게 만들지 마세요. 이렇게 느껴서는 안 됩니다.

복잡성과 상관없이 모든 유형의 테스트에서는 단순성을 목표로 해야 합니다. 실제로 테스트가 복잡할수록 단순화하는 것이 더 중요합니다. 이를 달성하는 한 가지 방법은 테스트를 최대한 간단하게 유지하고 필요한 항목만 테스트하는 플랫 테스트 설계를 사용하는 것입니다. 즉, 각 테스트에는 하나의 테스트 사례만 포함되어야 하며 테스트 사례는 하나의 특정 기능이나 기능을 테스트하는 데 중점을 두어야 합니다.

이러한 관점에서 생각해 보세요. 실패 테스트를 읽을 때 무엇이 잘못되었는지 쉽게 식별할 수 있어야 합니다. 테스트를 간단하고 이해하기 쉽게 유지하는 것이 중요한 이유입니다. 이렇게 하면 문제가 발생했을 때 신속하게 파악하고 해결할 수 있습니다.

가치 테스트

또한 플랫 테스트 설계는 집중력을 높이고 테스트에 유의미한 정보를 제공하는 데 도움이 됩니다. 커버리지를 목적으로 테스트를 만드는 것은 바람직하지 않습니다. 항상 목적이 있어야 합니다.

모든 것을 테스트하지는 마세요.

구현 세부정보 테스트 안함

테스트에서 흔히 발생하는 문제 중 하나는 구성요소 또는 엔드 투 엔드 테스트에서 선택기를 사용하는 것과 같이 구현 세부정보를 테스트하도록 테스트가 설계된다는 점입니다. 구현 세부정보란 코드 사용자가 일반적으로 사용하지 않거나, 보거나, 알지도 못하는 것들을 의미합니다. 이로 인해 테스트에서 거짓음성과 거짓양성이라는 두 가지 주요 문제가 발생할 수 있습니다.

거짓음성은 테스트된 코드가 올바르더라도 테스트가 실패하면 발생합니다. 애플리케이션 코드의 리팩터링으로 인해 구현 세부정보가 변경되면 이 문제가 발생할 수 있습니다. 반면 테스트 중인 코드가 올바르지 않더라도 테스트를 통과하면 거짓양성이 발생합니다.

이 문제를 해결하는 한 가지 방법은 다양한 유형의 사용자를 고려하는 것입니다. 최종 사용자와 개발자는 접근 방식이 다를 수 있으며 코드와 상호작용하는 방법도 다릅니다. 테스트를 계획할 때는 사용자가 보거나 상호작용할 내용을 고려하고 구현 세부정보 대신 이러한 요소에 따라 테스트를 진행하는 것이 중요합니다.

예를 들어 변경 빈도가 낮은 선택자를 선택하면 CSS 선택자 대신 data-attributes를 사용하는 등 테스트의 안정성을 높일 수 있습니다. 자세한 내용은 Kent C. Dodds의 게시글을 확인해 보거나 계속해서 관심을 갖고 지켜봐 주세요. 이 주제에 관한 기사는 나중에 제공될 예정입니다.

모의 처리: 컨트롤을 잃지 마세요

모의 처리는 단위 테스트와 때로는 통합 테스트에 사용되는 광범위한 개념입니다. 애플리케이션을 완전히 제어하는 종속 항목을 시뮬레이션하기 위해 모조 데이터 또는 구성요소를 만드는 작업이 포함됩니다. 이렇게 하면 격리된 테스트가 가능합니다.

테스트에서 모의 실험을 사용하면 예측 가능성, 문제 분리, 성능을 개선할 수 있습니다. 그리고 여권 인증과 같이 사람의 개입이 필요한 테스트를 수행해야 하는 경우 모의 도구를 사용하여 숨겨야 합니다. 이러한 이유로 모의 스크린샷은 유용한 도구입니다.

동시에 모의 테스트는 실제 사용자 환경이 아니라 모의 테스트이므로 테스트의 정확성에 영향을 미칠 수 있습니다. 따라서 모의 및 스텁을 사용할 때는 주의해야 합니다.

엔드 투 엔드 테스트에서 모의 테스트를 수행해야 하나요?

일반적으로 그렇지 않습니다. 그러나 모의가 때로는 구호가 될 수 있으므로 완전히 배제하지는 마세요.

서드 파티 결제 시스템 공급자 서비스와 관련된 기능에 대한 테스트를 작성한다고 가정해 보겠습니다. 해당 업체에서 제공한 샌드박스 환경에 있으며, 이는 실제 거래가 발생하지 않음을 의미합니다. 안타깝게도 샌드박스가 오작동하여 테스트가 실패합니다. 결제 시스템 공급자가 문제를 해결해야 합니다. 제공업체에서 문제를 해결할 때까지 기다리시면 됩니다.

이 경우에는 제어할 수 없는 서비스에 대한 의존성을 줄이는 것이 더 유익할 수 있습니다. 모의 테스트는 통합 테스트나 엔드 투 엔드 테스트에서 테스트의 신뢰도를 떨어뜨리므로 신중하게 사용하는 것이 좋습니다.

테스트 세부사항: 권장사항 및 금지사항

그렇다면 테스트에는 무엇을 포함할 수 있을까요? 테스트 유형 간에 차이가 있나요? 주요 테스트 유형에 맞춤화된 몇 가지 측면에 대해 자세히 살펴보겠습니다.

좋은 단위 테스트에 포함되는 것은 무엇인가요?

이상적이고 효과적인 단위 테스트는 다음과 같아야 합니다.

  • 특정 측면에 집중하세요.
  • 독립적으로 운영됩니다.
  • 소규모 시나리오를 포괄합니다.
  • 설명이 포함된 이름을 사용합니다.
  • 해당하는 경우 AAA 패턴을 따르세요.
  • 포괄적인 테스트 적용 범위 보장
권장사항 ✅ 금지사항 ❌
테스트를 최대한 작게 유지합니다. 테스트 사례당 하나의 항목을 테스트합니다. 큰 단위에 테스트를 작성합니다.
테스트를 항상 격리된 상태로 유지하고 단위 외부에 있는 필요한 항목을 모의 처리합니다. 다른 구성요소 또는 서비스를 포함합니다.
테스트를 독립적으로 유지합니다. 이전 테스트를 활용하거나 테스트 데이터를 공유합니다.
다양한 시나리오와 경로를 살펴봅니다. 최대한 행복한 경로 또는 네거티브 테스트로 제한합니다.
내용을 잘 나타내는 테스트 제목을 사용하면 테스트 내용을 바로 확인할 수 있습니다. 함수 이름만으로 테스트하며, 결과가 testBuildFoo() 또는 testGetId()와 같이 충분히 설명되지 않습니다.
특히 이 단계에서 우수한 코드 적용 범위나 더 광범위한 테스트 사례를 목표로 하세요. 모든 클래스에서 데이터베이스 (I/O) 수준까지 테스트합니다.

좋은 통합 테스트에 포함되는 것은 무엇인가요?

이상적인 통합 테스트는 단위 테스트와 몇 가지 기준을 공유합니다. 그러나 몇 가지 더 고려해야 할 사항이 있습니다. 훌륭한 통합 테스트의 특징은 다음과 같습니다.

  • 구성요소 간의 상호작용을 시뮬레이션합니다.
  • 실제 시나리오를 다루고 모의 또는 스텁을 사용합니다.
  • 실적을 고려하세요.
권장사항 ✅ 금지사항 ❌
통합 지점을 테스트합니다. 각 단위가 서로 통합될 때 원활하게 작동하는지 확인합니다. 각 단위를 격리된 상태로 테스트합니다. 이 것이 단위 테스트의 목적입니다.
실제 시나리오 테스트: 실제 데이터에서 파생된 테스트 데이터를 사용합니다. 자동 생성된 반복적인 테스트 데이터 또는 실제 사용 사례를 반영하지 않는 기타 데이터를 사용합니다.
외부 종속 항목의 모의 및 스텁을 사용하여 전체 테스트를 제어합니다. 타사 서비스에 대한 종속 항목(예: 외부 서비스에 대한 네트워크 요청)을 만듭니다.
각 테스트 전후에 정리 루틴을 사용합니다. 테스트 내부에서 정리 방법을 사용하는 것을 잊어버리세요. 그렇지 않으면 적절한 테스트 격리 부족으로 인해 테스트 실패 또는 거짓양성이 발생할 수 있습니다.

좋은 엔드 투 엔드 테스트에 포함되는 것은 무엇인가요?

포괄적인 엔드 투 엔드 테스트는 다음을 실행해야 합니다.

  • 사용자 상호작용을 복제합니다.
  • 중요한 시나리오를 포괄합니다.
  • 여러 레이어에 걸쳐 있습니다.
  • 비동기 작업을 관리합니다.
  • 결과를 확인합니다.
  • 실적을 고려합니다.
권장사항 ✅ 금지사항 ❌
API 기반 단축키를 사용합니다. 자세히 알아보세요. beforeEach 후크를 비롯한 모든 단계에 UI 상호작용을 사용합니다.
각 테스트 전에 정리 루틴을 사용합니다. 부작용의 위험이 높으므로 단위 테스트와 통합 테스트에서보다 테스트 격리를 더욱 주의합니다. 각 테스트 후 정리하는 것을 잊지 마세요. 남은 상태, 데이터 또는 부작용을 정리하지 않으면 나중에 실행되는 다른 테스트에 영향을 미칩니다.
엔드 투 엔드 테스트를 시스템 테스트로 간주합니다. 즉, 전체 애플리케이션 스택을 테스트해야 합니다. 각 단위를 격리된 상태로 테스트합니다. 이 것이 단위 테스트의 목적입니다.
테스트 내에서 모의 처리를 최소화하거나 사용하지 않습니다. 외부 종속 항목을 모의 처리할 때는 신중하게 고려하세요. 모의 스크린샷에 크게 의존합니다.
예를 들어 동일한 테스트에서 대규모 시나리오를 과도하게 테스트하지 않는 방식으로 성능과 워크로드를 고려합니다. 바로가기를 사용하지 않고 대규모 워크플로를 처리합니다.