답변.

자동화 테스트는 시스템 검사를 다른 수준에서 포괄적으로 수행하기 위해 유닛(unit), 통합(integration), 엔드 투 엔드(end-to-end, E2E)로 나뉩니다.

문제의 역사: 이 분류는 응용 프로그램을 부분과 전체로 테스트해야 할 필요성에서 비롯되었습니다. 따라서 테스트 층을 구분합니다:

문제: 오류는 종종 개별 메서드의 논리뿐만 아니라 구성 요소 간의 상호 작용이나 외부 서비스와 함께 전체 시스템을 "실제로" 실행할 때 발생합니다. 모든 것을 한 데 묶으면 버그를 빠르게 국지화하거나 정확히 어디에서 발생했는지 이해하기가 어렵습니다.

해결책:

유닛 테스트는 일반적으로 함수나 간단한 클래스의 수준에서 격리된 코드를 검사합니다. 발전된 경우에는 목(mock)과 스텁(stub)을 사용합니다.
통합 테스트는 여러 구성 요소(예: 모듈과 DB)를 연결하여 이들이 함께 어떻게 작동하는지를 확인합니다.
엔드 투 엔드 테스트(E2E)는 사용자 시나리오를 시뮬레이션합니다 — "버튼에서 결과까지"의 모든 경로입니다.

테스트 유형을 구별하는 것은 생명선입니다:

주요 특징:

함정 질문.

통합 테스트를 단순히 "큰" 유닛 테스트로 간주할 수 있습니까?

아니요, 통합 테스트는 여러 구성 요소의 작동을 테스트하며, 단지 개별 기능만을 확인하지 않습니다. 이 경우 실제 서비스 간의 상호 작용이 발생하므로 목을 사용하는 것이 항상 가능하지 않습니다.

모든 테스트가 엔드 투 엔드(E2E)여야 합니까?

아니요, 이는 비싸고 복잡한 접근입니다. E2E는 중요한 사용자 시나리오에만 필요하며, 대부분의 논리는 다른 테스트로 담고 있습니다.

유닛 테스트는 항상 빠릅니까?

항상 그런 것은 아닙니다. 코드를 격리할 수 없거나 메서드가 복잡한 외부 리소스에 의존하는 경우도 있습니다. 이런 경우 테스트는 유닛이 아닙니다.

회사는 주요 기능을 E2E 테스트로만 커버했습니다 — 모든 수정 사항은 밤에 검사되었고 테스트는 불안정하게 실패했으며 버그는 늦게 발견되었습니다.

장점:

단점:

팀은 테스트 피라미드를 구축했습니다: 하부 — 유닛 테스트, 중간 — 통합 테스트, 상부 — 가장 중요한 E2E만.

장점:

단점: