서로 다른 유형의 테스트에 지정된 이름은 코드베이스 전반에서 공통적인 주제를 갖는 경향이 있지만, 특별히 엄격한 정의가 포함되어 있지는 않습니다. 이 과정에서는 각 테스트 유형의 의미에 관한 가이드라인을 제공하지만 다른 리소스에서 다른 정의를 제공할 수 있습니다.
이전 페이지에는 단위 테스트와 구성요소 테스트 (이 예에서는 React 구성요소)의 예가 모두 있었습니다. 두 가지 모두 테스트 피라미드 (또는 다른 형태)에 낮게 배치할 수 있습니다. 복잡성이 낮고 실행이 빠르지만 좀 더 복잡한 통합 테스트만큼 유용성이 떨어질 수 있기 때문입니다.
일반적인 테스트 유형
단위 테스트
단위 테스트는 범위가 가장 작습니다. 일반적으로 코드의 작은 부분이나 순전히 스테이트리스(Stateless) 코드를 거의 수학적 방식으로 테스트하는 데 사용됩니다. 코드에 입력 X, Y, Z를 제공하면 출력은 A, B, C가 되어야 합니다.
단위 테스트가 포함된 코드에는 일반적으로 네트워크에서 가져오거나 다른 함수나 라이브러리를 암시적으로 사용하는 등의 외부 종속 항목이 없습니다. 개발자가 자체적으로 '잘라내고' 테스트할 수 있는 코드의 트리 노드입니다.
단위 테스트는 빠르게 작성하고 실행할 수 있지만 작은 코드 단위를 테스트해도 유용한 정보를 얻지 못할 가능성이 항상 있습니다. 코드 단위가 다른 코드와 상호작용하지 않으면 더 높은 수준에서 테스트하여 위험을 줄이는 것이 더 좋은 경우가 많습니다.
구성요소 테스트
웹 개발자의 경우 '구성요소'라는 이름이 오버로드됩니다. 이는 종종 React 구성요소 또는 웹 구성요소와 같이 사용자에게 표시되는 구성요소를 의미합니다. 보다 일반적인 정의는 테스트 가능한 작업 청크(예: 외부 종속 항목이 있는 클래스)입니다. 효과적으로 테스트하려면 이 구성요소의 종속 항목이 모의 처리되거나 건너뛰어야 합니다.
오늘날의 웹 개발 방식은 구성요소라는 개념을 기반으로 하므로 구성요소 테스트는 테스트에 관해 실제로 생각할 수 있는 방법입니다. 예를 들어 각 구성요소에 테스트가 필요하다고 결정할 수 있습니다. 또한 단일 개발자나 소규모 팀이 구성요소에 대한 명확한 소유권을 주장하는 상황에서도 구성요소 테스트를 간단하게 후속 조치를 취할 수 있습니다. 그러나 복잡한 종속 항목은 모의 처리하기 어려울 수 있습니다.
통합 테스트
이러한 테스트는 구성요소, 모듈, 하위 시스템 또는 코드의 기타 중요한 부분을 소규모로 그룹화하여 함께 테스트하여 제대로 작동하는지 확인하는 경향이 있습니다. 이것은 매우 모호한 정의입니다. 웹 개발자의 경우, 테스트 중인 코드가 사이트의 실제 프로덕션 빌드는 아니더라도 시스템의 다양한 관련 구성요소를 연결한다고 생각해 보세요.
여기에는 순수 모의 버전이 아닌 테스트 모드의 외부 데이터베이스와 같은 '실제' 종속 항목이 포함될 수도 있습니다. 예를 들어 query()가 항상 동일한 두 항목을 반환한다고 말하지 않고 통합 테스트를 통해 테스트 데이터베이스에 무언가가 있는지 확인할 수 있습니다. 데이터 자체는 덜 중요하지만 이제 데이터베이스를 연결하고 쿼리할 수 있는지 테스트하고 있습니다.
어설션을 사용하여 확인할 수 있는 광범위한 함축적인 의미를 갖는 비교적 간단한 통합 테스트를 작성할 수 있습니다. 다양한 구성요소에 연결된 단일 작업이 일련의 측정 가능한 효과를 일으킬 수 있기 때문입니다.
따라서 통합 테스트를 통해 복잡한 시스템이 의도한 대로 실행되는지 효과적으로 확인할 수 있습니다. 그러나 작성하고 유지 관리하기가 어려울 수 있으며 불필요한 복잡성이 발생할 수 있습니다. 예를 들어 통합 테스트를 위해 FakeUserService를 작성하면 테스트와 RealUserService 모두 UserService를 구현해야 한다는 요구사항이 추가됩니다.
스모크 테스트
매우 빠르게 완료되고 코드베이스가 적절한 상태인지 확인하는 테스트입니다. 실제로 이는 주로 사용자 환경에 광범위한 영향을 미치는 코드로 간단한 테스트를 실행하는 것을 의미합니다.
예를 들어 로그인된 대규모 웹 앱에서는 로그인 및 인증 시스템이 제대로 작동하지 않을 수 있습니다. 로그인 및 인증 시스템이 없으면 앱을 사용할 수 없고 추가 테스트도 진행되지 않기 때문입니다.
스모크 테스트는 대규모 코드베이스에서 package.json의 test 스크립트로 실행하기에 적합합니다. 수동 테스트는 일종의 스모크 테스트로도 사용될 수 있습니다.
회귀 테스트
회귀 테스트는 새 버전이나 기타 기능 개발 후 기존 기능이 계속 작동하거나 오래된 버그가 다시 발생하지 않는지 확인하는 스모크 테스트의 한 유형입니다.
이는 테스트 기반 개발 (TDD)의 개념과 관련이 있습니다. 버그를 명시적으로 트리거하도록 작성되고 나중에 버그가 수정되었는지 확인하는 데 사용되는 테스트 사례는 회귀 테스트 사례로 간주됩니다. 이 테스트 사례가 존재하면 동일한 버그가 반환되지 않아야 하기 때문입니다.
그러나 회귀 테스트는 훌륭한 솔루션이 없다면 문제가 될 수 있습니다. 비즈니스 요구사항에서 종종 언급되는 용어입니다. 기능이 개발될 때 기존 기능이 손상되지 않는 것이 중요합니다. 잘 테스트된 코드베이스는 이를 유지할 수 있어야 하지만 실제 코드베이스가 항상 이 이상에 부합하지는 않습니다. 이 내용은 이후 섹션에서 자세히 다룹니다.
시각적 테스트
시각적 테스트에는 웹사이트 상태의 스크린샷이나 동영상을 촬영하여 현재 테스트 실행과 비교하여 정상 상태 (예: 이전 스크린샷)를 확인하는 작업이 포함됩니다. 특성상 HTML, CSS, 웹사이트의 다른 부분을 렌더링할 수 있도록 실제 브라우저가 실행되어야 합니다.
전체 코드베이스를 실행하는 엔드 투 엔드 테스트를 시각적으로 테스트하는 대신, 특히 다양한 화면 크기에서 특정 구성요소만 렌더링하여 반응형 UI를 트리거하는 HTML '하네스'를 빌드하는 것이 유용할 수 있습니다. 이는 JSDOM 또는 유사한 프레임워크를만 사용하는 것보다 복잡합니다.
시각적 테스트 실패는 다른 종류의 파손의 좋은 신호일 수 있습니다. 그러나 복잡한 UI는 테스트하려는 기능과 관련 없는 이유(예: UI 모양을 변경하는 새로운 기능 또는 이전 버전과 다르게 그림 이모티콘을 렌더링하는 새 OS 버전)로 인해 시각적 테스트에 실패할 수 있습니다.
엔드 투 엔드 테스트
엔드 투 엔드 테스트는 테스트 피라미드의 맨 위에 있는 경우가 많습니다. 웹 앱 또는 웹사이트와의 전반적인 상호작용(특정 기능을 중심으로 할 수 있음)을 설명하며 일반적으로 WebdriverIO, Selenium 또는 Puppeteer와 같은 에이전트가 제어하는 브라우저 내에서 실행됩니다. 이들은 프로덕션에 배포되는 것처럼 코드베이스를 거의 실행할 수 있습니다(로컬에서 제공되는 경우가 많음).
사이트에 따라 테스트 사용자로 로그인하거나 주요 작업을 수행하며 사이트 또는 시스템이 올바른 상태인지 확인하는 작업이 포함될 수 있습니다. 이러한 유형의 테스트는 매우 강력하지만 때로는 관리하기가 까다롭기 때문에 이후 섹션에서 이러한 유형의 테스트 예를 더 많이 다룰 예정입니다.
범위를 간소화하거나 관련이 있는 경우 특정 구성요소를 모의 처리하는 방법으로 단순화할 수 있습니다. 예를 들어 사용자가 사이트에 로그인해야 하지만 로그인 기능이 테스트 중인 기능이 아니라면 테스트 환경에 플래그를 설정하여 테스트 컨트롤러가 로그인하거나 연결된 쿠키를 만들지 않고도 사용자 역할을 할 수 있도록 하는 것이 좋습니다.
엔드 투 엔드 테스트는 코드베이스의 거대한 교차 섹션을 한 번에 테스트할 수 있는 매우 강력한 방법일 수 있지만, 이러한 대규모 테스트는 외부 시스템에 대한 의존성으로 인해 불안정하거나 불안정할 수 있습니다. 또한 모든 테스트에서 항목을 만들거나 수정하는 경우 많은 테스트 데이터를 데이터베이스에 남겨둘 수도 있습니다. 이와 같이 남은 데이터가 축적되면 테스트의 실패 방식을 파악하기가 어려워질 수 있습니다.
API 테스트
API 테스트란 소프트웨어가 제공하는 API의 동작을 확인하거나 실제 API에 액세스하여 동작을 확인하는 것을 의미할 수 있습니다. 어느 쪽이든 이는 통합 테스트에서처럼 시스템 간의 추상화(결국 시스템이 서로 통신하는 방법)를 실제로 통합하지 않고 테스트하는 경향이 있습니다.
이러한 테스트는 상호 연결을 테스트하는 시스템의 실행 오버헤드 없이 통합 테스트의 기본적인 전초전을 제공할 수 있습니다. 하지만 실제 시스템 테스트는 불안정할 수 있습니다.
기타 유형
소스에 따라 유용할 수 있는 다른 다양한 테스트 접근 방식이 있습니다. 흥미로운 예는 다음과 같습니다.
- 수동 테스트.
- Agile에서 대중화한 수동 테스트의 일종인 승인 테스트는 제품이 '사용자의 요구사항을 충족'하는지 확인합니다.
- 카오스 테스트는 잘못된 데이터가 입력되어도 사이트가 다운되지 않도록 하기 위해 임의의 데이터를 입력하는 것을 의미합니다.
- 실패 테스트는 네트워크 장애와 같은 복잡한 시스템에서 의도적으로 장애를 시뮬레이션하여 테스트 중인 코드가 제어된 방식으로 응답하도록 합니다.
- 빌드 테스트는 코드베이스의 빌드 아티팩트가 존재하거나 그 콘텐츠가 무엇인지 확인하여 코드베이스의 빌드 아티팩트를 생성할 수 있는지 확인합니다. 이 테스트 유형은 복잡한 CMS의 출력을 확인하는 데 유용할 수 있습니다.
코드 적용 범위
자동 테스트로 테스트되는 코드의 비율을 측정하고 이를 시간 경과에 따른 통계로 보고할 수 있습니다. 코드 적용 범위를 100% 로 설정하지 않는 것이 좋습니다. 불필요한 오버헤드는 물론 주요 사용 사례를 자세히 다루지 않는 단순하거나 잘못 설계된 테스트로 이어질 수 있기 때문입니다.
적용 범위 자체는 테스트, 특히 통합 테스트를 작성하거나 작업할 때도 유용한 도구가 될 수 있습니다. 단일 테스트에서 테스트되는 코드의 비율 또는 줄별 분석을 표시하여 누락된 항목이나 다음에 테스트할 항목에 관한 유용한 정보를 얻을 수 있습니다.
자료
이해도 테스트
다음 중 알려진 테스트 유형은 무엇인가요?