답변.

이 질문의 배경:

처음에 자동화 테스트는 아키텍처 분리가 없이 "정면으로" 작성되었습니다: 검증 논리와 실행 메커니즘이 혼합되었습니다. 프로젝트가 성장함에 따라 프레임워크와 테스트 논리를 혼합하는 것이 취약하고 유지 보수가 어려운 코드베이스를 만든다는 것이 명확해졌습니다. 책임 분리를 위한 아키텍처 권장 사항이 등장했습니다.

문제:

테스트가 프레임워크의 내부 구현에 의존하거나 환경과의 상호작용 논리를 포함하는 경우, 어떤 변경도 많은 테스트를 다시 작성하게 강요합니다. 테스트 케이스가 복잡하고 코드가 중복되며 새로운 프레임워크나 플랫폼으로의 마이그레이션이 어렵습니다.

해결책:

엄격하게 분리해야 합니다:

프레임워크 (기본 인프라): 테스트 실행의 일반 메커니즘, 로깅, 오류 처리, 리포트, 보조 클래스(예: 드라이버, 어댑터 및 유틸리티)를 위한 기반.
테스트 논리 (테스트 케이스): 테스트의 의미적 목표를 표현하는 특정 시나리오로, 프레임워크의 공개 API만 사용합니다.

주요 특징:

플랫폼 변경에 대한 격리로 인한 유지보수 용이성
테스트 논리 재사용 가능성
코드의 중복성과 과잉 감소

함정 질문.

테스트가 아주 적은 경우 테스트 단계는 테스트에 직접 작성할 수 있나요?

안 됩니다. 짧은 테스트라도 커질 수 있으며, 층이 없으면 빠르게 혼란에 빠질 수 있습니다.

테스트 시나리오는 실행 메커니즘을 알아야 하나요 (예: 드라이버를 언제 초기화할지)?

아니요. 모든 인프라 세부사항은 프레임워크층에서 숨겨져야 합니다.

테스트 케이스 내에서 테스트 매개변수를 하드코딩하는 것이 괜찮은가요 (예: URL, 자격 증명)?

아니요. 테스트 매개변수는 프레임워크 및 환경 설정을 통해 구성되어야 합니다.

일반적인 오류 및 안티 패턴

프레임워크의 메서드 내에서 상태 검증을 위치시키는 것, 테스트가 아닌
테스트에서 프라이빗 메서드 사용
테스트의 보조 기능 중복
매개변수 하드코딩

실생활 사례

부정적인 케이스

프로젝트에서 테스트는 Selenium 드라이버의 메서드를 직접 호출하며, 각 테스트에서 WebDriver에 대한 연결이 반복됩니다. 각 테스트는 구성 파일을 독자적으로 파싱합니다.

장점:

아키텍처 없이 자동화 테스트를 빠르게 시작할 수 있습니다.

단점:

드라이버 변경이나 실행 매개변수 변경 시 대규모 수정이 필요합니다.
모든 테스트에서 중복된 코드가 존재합니다.
프로젝트 확장 및 유지보수가 어렵습니다.

긍정적인 케이스

테스트는 프레임워크의 기본 추상화를 사용합니다: 일반 초기화 및 teardown, 구성자를 통한 매개변수 전달, 테스트 논리는 고급 메서드를 통해 표현됩니다.