프론트엔드 테스트를 작성하는 것은 매우 어려울 수 있습니다. 고려해야 할 사항, 선택해야 할 사항, 선택할 수 있는 경로가 너무 많습니다. 이 글에서는 더 나은 테스트를 작성하기 위한 5가지 원칙을 살펴보고 새로운 기능을 프로덕션에 적용할 수 있는 자신감을 얻을 것입니다.
시작하기 전에 이 글에서는 프론트 엔드 테스트 에 중점을 두고 있으며, React 애플리케이션 및 컴포넌트와의 상호 작용을 기반으로 설명합니다.
그럼 5가지 프론트엔드 테스트 원칙에 대해서 알아보겠습니다.
원칙
1. 사용자가 사용하는 것과 동일한 방식으로 소프트웨어를 테스트합니다.
컴포넌트가 사용자를 위해 작동하고 있다는 높은 확신을 주는 유지 관리 가능한 테스트를 작성하고 싶습니다.
그리고 프론트엔드의 경우 테스트를 위한 두 가지 대상에만 집중해야 합니다.
- 브라우저에서 구성 요소와 상호 작용하는 최종 사용자.
- 코드에서 구성 요소를 렌더링하고 사용 하는 개발자.
당신의 테스트가 이 두 가지를 제공하는 한, 그것들은 존재할 이유가 있습니다.
그러나 너무 자주 우리는 세 번째 사용자인 테스트 사용자를 소개합니다. 이 사용자는 일반적으로 소비자나 비즈니스가 신경 쓰지 않는 항목을 테스트합니다(예: 구현 세부 정보 테스트).
그러나 이러한 방식으로 테스트하면 다음과 같은 사용자에 대한 확신을 얻을 수 있습니다.
- 최종 사용자 처럼 요금을 지불하지 않습니다 .
- 개발자 사용자 와 같이 나머지 시스템에는 영향을 미치지 않습니다 .
또한 이제 세 번째 사용자를 머릿속에 기억하고 테스트 사용자에게 영향을 미치는 변경 사항을 설명해야 합니다.
2. 구현 세부 사항을 테스트하지 마십시오.
테스트 사용자 는 "구현 세부 정보"라고 불리는 것을 테스트하는 경향이 있습니다 .
구현 세부 사항은 다음으로 이어질 수 있습니다.
- 거짓 부정: 애플리케이션 코드를 리팩터링할 때 중단될 수 있습니다.
- 가양성: 애플리케이션 코드를 깨뜨릴 때 실패하지 않을 수 있습니다.
이것이 대부분의 경우 우리가 피하고 싶어하는 이유이며 , 이는 우리의 테스트를 만들 것입니다:
- 사용자(최종 사용자 및 개발자)가 구성 요소를 사용하는 방식에 더 가깝습니다. 이는 애플리케이션이 의도한 대로 작동한다는 확신을 줍니다.
- 더 탄력적입니다. 귀하의 구성 요소의 리팩터는 테스트를 중단하지 않으므로 팀과 우리를 속도가 느려지지 않습니다.
테스트는 사용자가 충족할 수 있는 실제 사용 사례에 더 집중해야 합니다.
구현 세부 사항을 결정하는 방법은 무엇입니까?
— 테스트가 코드 소비자가 수행하지 않는 작업을 수행하는 경우 구현 세부 정보를 테스트하는 것입니다. (예를 들어 개인 기능 노출).
— 내부 리팩터링(기능이 아닌 구현에 대한 변경)이 테스트를 중단하는 경우 구현 세부정보를 테스트하는 것입니다."구현 세부 사항"의 예:
— 구성 요소의 내부 상태
— 구성 요소의 내부 메서드
— 구성 요소의 수명 주기 메서드
— 하위 구성 요소
구현 세부 정보를 테스트해야 하는 경우가 여전히 있다는 점에 유의하는 것이 중요합니다. React에서는 예를 들어 많은 내부 로직이 있고 애플리케이션 전체에서 공유되는 커스텀 훅에 대해 생각할 수 있습니다.
그러나 그것들은 드물고 잘 선택되어야 합니다.
3. 더 적은 수의 더 긴 테스트 작성
많은 사람들이 구성 요소에 대한 요구 사항 목록을 읽고 개별 테스트 사례로 전환합니다. 소위 "테스트 모범 사례당 단 하나의 주장"에 대해 읽었을 것입니다.
그러나 이 규칙은 원래 테스트 프레임워크가 테스트 실패의 원인을 파악하는 데 필요한 컨텍스트 정보를 제대로 제공하지 못했기 때문에 만들어졌습니다.
오늘날 우리의 놀라운 도구 덕분에 어떤 어설션이 실패를 초래했는지 식별하는 것은 간단합니다. 더 명확하게 하고 싶다면 주장 위에 코드 주석을 추가하여 주장에 대해 중요한 것을 설명할 수 있습니다.
긴 테스트가 있다고 걱정하지 마십시오. 두 사용자에 대해 생각하고 테스트 사용자 를 피할 때 테스트 에는 종종 여러 작업과 주장이 포함되며 이는 좋은 일입니다. 주장을 개별 테스트 블록으로 임의로 분리하지 마십시오. 그렇게 할 이유가 없습니다.
테스트를 결정하는 방법?
수동 테스터를 위한 테스트 케이스 워크플로를 생각하고 각 테스트 케이스에 해당 워크플로의 모든 부분을 포함하도록 하십시오.
3. 이해하기 쉽고 유지 관리 용이성을 염두에 두고 테스트 작성
AHA 프로그래밍 원칙 은 "성급한 추상화 방지" 의 약자입니다. 추상화 작성을 시작할 때 독단적이어서는 안 되며 대신 적절하다고 느낄 때 추상화를 작성하고 거기에 도달할 때까지 코드를 복제하는 것을 두려워하지 마십시오.
추상화 스펙트럼의 중간에서 최적의 지점을 찾는 것이 유지 관리 가능한 코드를 개발하는 데 중요합니다.
이 원칙은 유지 관리 가능한 테스트를 작성하는 데 완전히 적용될 수 있습니다. 다시 말해, 오늘 프로덕션에서 푸시하는 코드가 나중에 변경되더라도 중단되지 않을 것이라는 확신을 가지기 위해 테스트를 작성합니다. 그러나 테스트는 테스트된 구성 요소의 목적(기능 및 중요 기능 측면에서)이 무엇인지 쉽게 이해하기 위해 나중에 다시 돌아올 수 있는 사용자 또는 다른 개발자에게도 도움이 되어야 합니다. 이런 식으로 테스트를 이해하기 쉽고 유지 관리가 용이하게 하고 싶습니다 .
4. 격리된 테스트 작성
테스트를 격리한다는 것은 한 테스트 실행의 부작용이 다른 테스트의 결과에 영향을 미치지 않아야 함을 의미합니다. 얻은 결과를 변경하지 않고 어떤 순서로든 독립적으로 실행할 수 있어야 합니다.
테스트를 격리하는 것은 일반적으로 테스트의 중요한 원칙입니다. 왜냐하면 이것이 제대로 존중되지 않을 때 불안정한 테스트(테스트를 실행할 때마다 동일한 결과를 생성하지 못하는 테스트)의 가장 큰 원인 중 하나이기 때문입니다.
테스트는 독립 실행형이어야 하고 실행 순서는 중요하지 않으므로 Jest는 테스트를 병렬로 실행할 수 있으므로 총 실행 시간이 상당히 향상됩니다.
테스트를 개별적으로 작성하면 테스트를 작성하여 안정성을 개선하고 코드를 단순화하며 자신감을 높일 수 있는 더 나은 방법을 찾을 수 있습니다.
5. 모의 행위를 조심하라
Mock은 다른 방법으로는 테스트하기 어렵거나 게으른 특정 항목을 테스트할 수 있는 임시 메커니즘으로 간주됩니다(예: 신용 카드 서비스 테스트, 우리는 프로덕션의 데이터 및 서비스를 가지고 놀고 싶지 않으므로 실제 돈 ).
우리가 어떤 것을 조롱할 때 우리는 절충안을 만들고 있음을 명심하십시오 . 우리는 일반적으로 실용성을 위해 자신감을 거래합니다. 우리의 코드가 가짜 서비스 버전과 함께 작동한다고 확신하더라도 우리 코드가 실제 버전과 함께 프로덕션 환경에서 작동할 것이라고 100% 확신할 수는 없습니다.
확실히 모의(mocks)를 위한 장소가 있지만(특히, 다양한 수준의 테스트에 대해 이야기할 때), 우리는 절충을 해야 한다는 것을 의식할 필요가 있습니다.
결론
제가 이 글에서 말했듯이 프론트엔드 테스트는 어렵습니다. 관련 테스트를 작성하려면 자신의 개발자 사고 방식에서 벗어나 UI 전체를 고려하여 실제 사용자처럼 생각하려고 노력해야 합니다. 다른 개발자가 자신의 코드와 테스트를 추가하기 위해 당신을 뒤따를 것이기 때문에 유지 관리 가능성과 이해 가능성에도 많은 주의를 기울여야 합니다.
테스트를 작성하는 주요 목적은 애플리케이션에 대한 자신감을 높이는 것임을 기억하십시오. 구현된 기능이 현재 예상대로 작동하고 미래에 중단되지 않도록 하고 싶습니다. 테스트 작성을 위한 테스트 작성(또는 임의의 최소 코드 적용 범위와 일치)은 가치가 없으며 종종 시간과 비용 낭비를 초래합니다.
이 원칙이 여러분의 여정에 도움이 되기를 바랍니다.
읽어 주셔서 감사합니다.
