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

bookmark_border 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

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

Ramona Schwering

이전 도움말에서는 테스트 사례의 기본사항과 테스트 사례에 포함되어야 하는 항목을 다뤘습니다. 이 도움말에서는 기술적 관점에서 테스트 사례 생성을 자세히 살펴보고 각 테스트에 포함해야 할 항목과 피해야 할 항목을 설명합니다. 기본적으로 '테스트할 항목' 또는 '테스트하지 않을 항목'이라는 오래된 질문에 대한 답변을 배우게 됩니다.

일반 가이드라인 및 패턴

단위 테스트, 통합 테스트 또는 엔드 투 엔드 테스트 중 무엇을 실행하든 특정 패턴과 지점이 중요하다는 점에 유의하세요. 이러한 원칙은 두 가지 유형의 테스트에 모두 적용할 수 있고 적용해야 하므로 시작하기 좋은 곳입니다.

항상 간결하게

테스트를 작성할 때 가장 중요한 점은 간단하게 유지하는 것입니다. 두뇌의 용량을 고려하는 것이 중요합니다. 기본 프로덕션 코드는 상당한 공간을 차지하므로 추가 복잡성을 줄일 여지가 거의 없습니다. 이는 테스트의 경우 특히 그렇습니다.

여유 공간이 적으면 테스트에 더 집중할 수 있습니다. 따라서 테스트에서 간결성을 우선시하는 것이 중요합니다. 실제로 Yoni Goldberg의 JavaScript 테스트 권장사항에서는 금과옥조의 중요성을 강조합니다. 테스트는 복잡한 수학 공식이 아니라 보조 도구처럼 느껴야 합니다. 즉, 테스트의 의도를 한눈에 파악할 수 있어야 합니다.

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

실패한 테스트를 읽을 때 무엇이 잘못되었는지 쉽게 파악할 수 있어야 합니다. 따라서 테스트를 간단하고 이해하기 쉽게 유지하는 것이 중요합니다. 이렇게 하면 문제가 발생할 때 빠르게 파악하고 해결할 수 있습니다.

가치 있는 항목 테스트

또한 플랫 테스트 디자인은 집중력을 높이고 테스트의 의미를 보장하는 데 도움이 됩니다. 테스트는 적용 범위를 높이기 위해만 만들지 마세요. 테스트에는 항상 목적이 있어야 합니다.

구현 세부정보 테스트 안 함

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

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

이 문제의 한 가지 해결 방법은 다양한 사용자 유형을 고려하는 것입니다. 최종 사용자와 개발자의 접근 방식은 다를 수 있으며 코드와 상호작용하는 방식도 다를 수 있습니다. 테스트를 계획할 때는 사용자가 보거나 상호작용할 항목을 고려하고 테스트가 구현 세부정보가 아닌 이러한 항목에 종속되도록 해야 합니다.

예를 들어 변경될 가능성이 적은 선택자를 선택하면 테스트의 안정성을 높일 수 있습니다(CSS 선택자 대신 data-attributes). 자세한 내용은 켄트 C. Dodds의 도움말을 참고하거나 이 주제에 관한 도움말이 제공될 때까지 기다려 주세요.

조롱: 냉정하게 대처하기

모의 처리는 단위 테스트에서 사용되는 광범위한 개념으로, 경우에 따라 통합 테스트에서도 사용됩니다. 애플리케이션을 완전히 제어할 수 있는 종속 항목을 시뮬레이션하기 위해 가짜 데이터 또는 구성요소를 만드는 것이 포함됩니다. 이렇게 하면 격리된 테스트가 가능합니다.

테스트에서 모의 항목을 사용하면 예측 가능성, 관심사 분리, 성능을 개선할 수 있습니다. 또한 사람의 개입이 필요한 테스트 (예: 여권 확인)를 실행해야 하는 경우 모의 테스트를 사용하여 이를 숨겨야 합니다. 이러한 모든 이유로 모의 처리는 고려할 만한 가치가 있는 도구입니다.

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

엔드 투 엔드 테스트에서 모의 처리해야 하나요?

일반적으로 그렇지 않습니다. 하지만 모의 처리가 도움이 될 때도 있으므로 완전히 배제하지는 마세요.

서드 파티 결제 제공업체 서비스와 관련된 기능의 테스트를 작성하는 시나리오를 가정해 보겠습니다. 제공된 샌드박스 환경에 있으므로 실제 거래는 이루어지지 않습니다. 샌드박스가 제대로 작동하지 않아 테스트가 실패했습니다. 결제 제공업체에서 수정해야 합니다. 제공업체에서 문제를 해결할 때까지 기다리는 수밖에 없습니다.

이 경우 제어할 수 없는 서비스에 대한 종속성을 줄이는 것이 더 유용할 수 있습니다. 하지만 통합 테스트 또는 엔드 투 엔드 테스트에서는 테스트의 신뢰도 수준이 낮아지므로 모의 처리를 신중하게 사용하는 것이 좋습니다.

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

그렇다면 테스트에는 무엇이 포함되나요? 테스트 유형 간에 차이가 있나요? 주요 테스트 유형에 맞게 조정된 몇 가지 구체적인 측면을 자세히 살펴보겠습니다.

좋은 단위 테스트의 특징은 무엇인가요?

이상적이고 효과적인 단위 테스트는 다음을 충족해야 합니다.

• 특정 측면에 집중합니다.
• 독립적으로 작동합니다.
• 소규모 시나리오를 포함합니다.
• 설명이 포함된 이름을 사용합니다.
• 해당하는 경우 AAA 패턴을 따릅니다.
• 포괄적인 테스트 적용 범위를 보장합니다.

좋은 통합 테스트에는 무엇이 포함되나요?

이상적인 통합 테스트는 단위 테스트와도 일부 기준을 공유합니다. 하지만 몇 가지 추가 사항을 고려해야 합니다. 우수한 통합 테스트는 다음을 충족해야 합니다.

• 구성요소 간의 상호작용을 시뮬레이션합니다.
• 실제 시나리오를 다루고 모의 또는 스텁을 사용하세요.
• 실적을 고려하세요.

우수한 엔드 투 엔드 테스트에는 무엇이 포함되나요?

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

• 사용자 상호작용을 복제합니다.
• 중요한 시나리오를 포함합니다.
• 여러 레이어에 걸쳐 있습니다.
• 비동기 작업을 관리합니다.
• 결과를 확인합니다.
• 실적을 고려합니다.