이전 기사에서는 테스트 케이스의 기본 사항과 포함해야 할 내용을 다루었습니다. 이 기사에서는 기술적인 관점에서 테스트 사례 생성에 대해 더 자세히 살펴보고 각 테스트에 포함되어야 할 사항과 피해야 할 사항을 자세히 설명합니다. 기본적으로 "무엇을 테스트해야 하는지" 또는 "무엇을 테스트하지 말아야 하는지"라는 오래된 질문에 대한 답을 배우게 됩니다.
테스트할 것과 테스트하지 않을 것.
일반 지침 및 패턴 #
단위, 통합 또는 엔드투엔드 테스트를 수행하는지 여부에 관계없이 특정 패턴과 점이 중요하다는 점은 주목할 가치가 있습니다. 이러한 원칙은 두 가지 테스트 유형 모두에 적용될 수 있고 적용되어야 하므로 시작하기에 좋은 곳입니다.
간단하게 #
테스트를 작성할 때 기억해야 할 가장 중요한 것 중 하나는 단순함을 유지하는 것입니다. 뇌의 용량을 고려하는 것이 중요합니다. 주요 프로덕션 코드는 상당한 공간을 차지하므로 추가 복잡성이 발생할 여지가 거의 없습니다. 이는 특히 테스트에 해당됩니다.
사용 가능한 여유 공간이 적으면 테스트 작업이 더 편안해질 수 있습니다. 그렇기 때문에 테스트의 단순성을 우선시하는 것이 중요합니다. 실제로 Yoni Goldberg의 JavaScript 테스트 모범 사례는 황금률의 중요성을 강조합니다. 테스트는 복잡한 수학 공식이 아니라 보조자처럼 느껴져야 합니다. 즉, 테스트의 의도를 한눈에 이해할 수 있어야 합니다.
테스트를 복잡하게 만들지 마십시오. 그렇게 느껴서는 안됩니다.
복잡성에 관계없이 모든 유형의 테스트에서 단순성을 목표로 해야 합니다. 실제로 테스트가 복잡할수록 단순화하는 것이 더욱 중요합니다. 이를 달성하는 한 가지 방법은 테스트를 가능한 한 단순하게 유지하고 필요한 것만 테스트하는 플랫 테스트 디자인을 사용하는 것입니다. 즉, 각 테스트에는 하나의 테스트 사례만 포함되어야 하며 테스트 사례는 단일 특정 기능이나 특징을 테스트하는 데 중점을 두어야 합니다.
이런 관점에서 생각해 보세요. 실패한 테스트를 읽을 때 무엇이 잘못되었는지 식별하는 것이 쉬워야 합니다. 그렇기 때문에 테스트를 간단하고 이해하기 쉽게 유지하는 것이 중요합니다. 이렇게 하면 문제가 발생할 때 신속하게 식별하고 수정할 수 있습니다.
무엇이 가치 있는지 테스트해 보세요 #
또한 플랫 테스트 디자인은 집중력을 높이고 테스트가 의미가 있는지 확인하는 데 도움이 됩니다. 단지 적용 범위를 위해서만 테스트를 만드는 것이 아니라 항상 목적이 있어야 한다는 점을 기억하십시오.
모든 것을 테스트하지 마십시오.
이전 기사 에서는 테스트 노력의 우선순위를 정할 때 기억해야 할 세 가지 핵심 사항에 대해 논의했습니다. 이 세 가지 우선순위는 문제의 사례가 테스트에 포함되어야 하는지 결정하는 데 도움이 될 수 있습니다.
구현 세부 사항을 테스트하지 마세요 #
테스트에서 흔히 발생하는 문제 중 하나는 테스트가 구성 요소의 선택기 사용이나 엔드투엔드 테스트와 같은 구현 세부 사항을 테스트하도록 설계되는 경우가 많다는 것입니다. 구현 세부 사항은 코드 사용자가 일반적으로 사용하거나 보거나 알지 못하는 항목을 나타냅니다. 이로 인해 테스트에서 거짓음성(false negatives)과 거짓양성(false positives)이라는 두 가지 주요 문제가 발생할 수 있습니다.
테스트된 코드가 정확하더라도 테스트가 실패하면 거짓음성이 발생합니다. 이는 애플리케이션 코드의 리팩토링으로 인해 구현 세부 사항이 변경될 때 발생할 수 있습니다. 반면, 테스트 중인 코드가 올바르지 않은 경우에도 테스트를 통과하면 거짓 긍정이 발생합니다.
이 문제에 대한 한 가지 해결책은 다양한 유형의 사용자를 고려하는 것입니다. 최종 사용자와 개발자는 접근 방식이 다를 수 있으며 코드와 다르게 상호 작용할 수 있습니다. 테스트를 계획할 때 사용자가 무엇을 보거나 상호 작용할지 고려하고 구현 세부 사항 대신 테스트가 이러한 항목에 종속되도록 만드는 것이 중요합니다.
예를 들어, 변경될 가능성이 적은 선택기를 선택하면 테스트의 신뢰성이 더욱 높아질 수 있습니다. 즉, CSS 선택기 대신 데이터 속성을 사용하는 것입니다. 자세한 내용은 이 주제에 대한 Kent C. Dodds의 기사를 참조 하거나 계속 지켜봐 주시기 바랍니다. 이 주제에 대한 기사는 나중에 나올 예정입니다.
반대로 테스트를 잘 작성하면 코드의 테스트 가능성을 고려할 때 소스 코드 구조에 긍정적인 영향을 미칠 수도 있습니다.
조롱: 통제력을 잃지 마세요 #
모의는 단위 테스트와 때로는 통합 테스트에 사용되는 광범위한 개념입니다. 여기에는 애플리케이션을 완전히 제어할 수 있는 종속성을 시뮬레이션하기 위해 가짜 데이터나 구성 요소를 생성하는 작업이 포함됩니다. 이를 통해 격리된 테스트가 가능합니다.
테스트에 모의 테스트를 사용하면 예측 가능성, 문제 분리 및 성능이 향상될 수 있습니다. 그리고 사람의 개입이 필요한 테스트(예: 여권 확인)를 수행해야 하는 경우 모의를 사용하여 이를 숨겨야 합니다. 이러한 모든 이유로 인해 모의 모형은 고려해야 할 귀중한 도구입니다.
동시에, 모의는 실제 사용자 경험이 아닌 모의이기 때문에 테스트의 정확성에 영향을 미칠 수 있습니다. 따라서 모의 객체와 스텁을 사용할 때는 주의해야 합니다.
엔드투엔드 테스트에서 모의해야 합니까? #
일반적으로 그렇지 않습니다. 그러나 조롱은 때때로 생명의 은인이 될 수 있으므로 완전히 배제하지는 마십시오.
이 시나리오를 상상해 보십시오. 제3자 결제 제공업체 서비스와 관련된 기능에 대한 테스트를 작성하고 있습니다. 귀하는 그들이 제공하는 샌드박스 환경에 있으며, 이는 실제 거래가 발생하지 않음을 의미합니다. 불행하게도 샌드박스가 제대로 작동하지 않아 테스트가 실패합니다. 문제는 결제 서비스 제공업체에서 해결해야 합니다. 당신이 할 수 있는 일은 공급자가 문제를 해결할 때까지 기다리는 것뿐입니다.
이 경우 제어할 수 없는 서비스에 대한 종속성을 줄이는 것이 더 유리할 수 있습니다. 통합 또는 엔드투엔드 테스트에서는 모의 테스트를 신중하게 사용하는 것이 좋습니다. 테스트의 신뢰도 수준이 떨어지기 때문입니다.
테스트 세부 사항: 해야 할 일과 하지 말아야 할 일 #
그렇다면 전체적으로 테스트에는 무엇이 포함됩니까? 그리고 테스트 유형 간에 차이가 있나요? 주요 테스트 유형에 맞춰진 몇 가지 특정 측면을 자세히 살펴보겠습니다.
좋은 단위 테스트에는 무엇이 포함됩니까? #
이상적이고 효과적인 단위 테스트는 다음을 충족해야 합니다.
특정 측면에 집중하십시오.
독립적으로 운영합니다.
소규모 시나리오를 포괄합니다.
설명적인 이름을 사용하십시오.
해당되는 경우 AAA 패턴을 따르세요.
포괄적인 테스트 범위를 보장합니다.
✅ 하지마 ❌
테스트를 가능한 한 작게 유지하십시오. 테스트 케이스당 하나씩 테스트합니다. 큰 단위에 대한 테스트를 작성합니다.
항상 테스트를 분리하여 유지하고 장치 외부에 필요한 것을 모의하십시오. 다른 구성 요소나 서비스를 포함합니다.
테스트를 독립적으로 유지하십시오. 이전 테스트를 활용하거나 테스트 데이터를 공유하세요.
다양한 시나리오와 경로를 다룹니다 . 최대한 행복한 길이나 부정적인 테스트로 자신을 제한하십시오.
설명적인 테스트 제목을 사용하면 테스트 내용을 즉시 확인할 수 있습니다. 함수 이름만으로 테스트하고 결과를 충분히 설명하지 못함: testBuildFoo()또는 testGetId().
특히 이 단계에서는 좋은 코드 적용 범위나 더 넓은 범위의 테스트 사례를 목표로 하세요. 모든 클래스부터 데이터베이스(I/O) 수준까지 테스트합니다.
좋은 통합 테스트란 무엇인가? #
이상적인 통합 테스트는 단위 테스트와도 몇 가지 기준을 공유합니다. 그러나 고려해야 할 몇 가지 추가 사항이 있습니다. 훌륭한 통합 테스트는 다음을 충족해야 합니다.
구성 요소 간의 상호 작용을 시뮬레이션합니다.
실제 시나리오를 다루고 모의 또는 스텁을 사용합니다.
성능을 고려하십시오.
✅ 하지마 ❌
통합 지점 테스트: 각 장치가 서로 통합될 때 원활하게 함께 작동하는지 확인합니다. 각 단위를 개별적으로 테스트합니다. 이것이 바로 단위 테스트의 목적입니다.
실제 시나리오 테스트: 실제 데이터에서 파생된 테스트 데이터를 사용합니다. 반복적으로 자동 생성된 테스트 데이터나 실제 사용 사례를 반영하지 않는 기타 데이터를 사용하세요.
전체 테스트에 대한 제어를 유지하려면 외부 종속성에 대한 모의 및 스텁을 사용하세요. 외부 서비스에 대한 네트워크 요청과 같은 타사 서비스에 대한 종속성을 만듭니다.
각 테스트 전후에 청소 루틴을 사용하십시오. 테스트 내에서 정리 조치를 사용하는 것을 잊어버리십시오. 그렇지 않으면 적절한 테스트 격리가 부족하여 테스트 실패 또는 거짓 긍정이 발생할 수 있습니다.
좋은 엔드투엔드 테스트란 무엇일까요? #
포괄적인 엔드 투 엔드 테스트는 다음을 수행해야 합니다.
사용자 상호 작용을 복제합니다.
중요한 시나리오를 포괄합니다.
여러 레이어에 걸쳐 있습니다.
비동기 작업을 관리합니다.
결과를 확인합니다.
성과를 설명합니다.
✅ 하지마 ❌
API 기반 단축키를 사용하세요. 자세히 알아 보기 후크 를 포함한 모든 단계에서 UI 상호 작용을 사용하세요 beforeEach.
각 테스트 전에 청소 루틴을 사용하십시오. 여기에는 부작용이 발생할 위험이 더 높으므로 단위 및 통합 테스트에서보다 테스트 격리에 더 주의를 기울이십시오. 각 테스트 후에는 청소하는 것을 잊지 마세요. 남은 상태, 데이터 또는 부작용을 정리하지 않으면 나중에 실행되는 다른 테스트에 영향을 미칩니다.
엔드투엔드 테스트를 시스템 테스트로 간주하십시오. 이는 전체 애플리케이션 스택을 테스트해야 함을 의미합니다. 각 단위를 개별적으로 테스트합니다. 이것이 바로 단위 테스트의 목적입니다.
테스트 내에서는 최소한의 조롱을 사용하거나 조롱을 사용하지 마세요. 외부 종속성을 모의하려는 경우 신중하게 고려하십시오. mock에 크게 의존하세요.
예를 들어 동일한 테스트에서 대규모 시나리오를 과도하게 테스트하지 않도록 하여 성능과 작업 부하를 고려하십시오. 바로가기를 사용하지 않고도 대규모 작업 흐름을 처리할 수 있습니다.
