실제 브라우저를 지켜보며 실패한 E2E 테스트를 고친다

## 테스트 전에 브라우저에서 보이는 성공 상태를 정한다 종단 간 테스트를 실행하기 전에 요청된 동작을 실제 브라우저에서 관찰할 수 있는 조건으로 바꾼다. 시작 주소 또는 경로, 필요한 계정이나 테스트 픽스처 상태, 관련이 있는 경우의 뷰포트, 사용자 동작, 성공으로 인정할 정확한 가시적 결과를 기록한다. 접근성 상태, 탐색, 영구 저장 상태, 네트워크에서 가져오는 콘텐츠가 동작의 일부라면 함께 포함한다. - 스타일 클래스나 문서 객체 모델의 위치보다 안정적인 사용자용 역할, 레이블, 전용 테스트 식별자를 우선한다. - 테스트 실행기 인터페이스와 테스트 대상 애플리케이션을 구분한다. 한쪽의 증거가 다른 쪽의 상태를 자동으로 설명하지는 않는다. - 눈에 보이는 확인 표시나 변경된 값과 같은 긍정 증거와 오류 배너가 없다는 것과 같은 부정 증거를 모두 정의한다. - 시간 요구 사항은 임의의 지연 시간이 아니라 관찰 가능한 준비 완료 조건으로 표현한다. 테스트를 통과시키기 위해 검증문을 약화해서는 안 된다. 예상 동작이 모호하다면 테스트 코드나 제품 코드를 변경하기 전에 중단하고 인수 조건을 명확히 한다. ## 실제 브라우저에서 테스트를 실행하고 스크린샷과 로그를 남긴다 실제로 지원되는 브라우저에서 정상적인 애플리케이션 경로를 사용해 관련성이 가장 높은 최소 범위의 종단 간 시나리오를 실행한다. 설정, 테스트 픽스처 데이터, 인증 상태, 뷰포트, 기능 플래그를 실행을 반복할 수 있을 만큼 명시한다. 화면 표시 모드나 디버그 모드를 사용할 수 있다면 시각적 상태나 브라우저 상호작용이 중요할 때 사용한다. 실패하면 어떤 것도 수정하기 전에 다음 증거를 확보한다. - 실패한 시나리오와 정확한 검증문 또는 명령 - 실패 시점의 브라우저 화면 캡처 또는 상태 스냅샷 - 접근 가능한 이름과 상태를 포함한 대상 요소 주변의 애플리케이션 문서 객체 모델 - 관련 브라우저 콘솔 오류와 실패했거나 예상과 다른 네트워크 요청 - 현재 주소, 경로 전환, 로딩 표시, 애플리케이션에 표시된 오류 메시지 - 가능할 때 서버 기록과 연결하는 데 필요한 시각 또는 실행 식별자 관련 없는 상태를 대량으로 쏟아내지 말고 대상을 좁혀 조사한다. 안정적인 실패와 일시적인 실패를 구분해야 할 때는 같은 조건에서 한 번 재현하되, 제한 없는 재시도 루프를 시작해서는 안 된다. ## 실패 원인을 테스트, 코드, 환경 중 하나로 나눈다 관찰한 실패를 테스트 원인, 구현 원인 또는 환경 원인으로 분류한다. 분류는 브라우저 증거와, 필요한 경우 관련성이 가장 높은 최소 범위의 소스 코드 또는 기록 조사로 뒷받침해야 한다. - 테스트 원인: 제품은 인수 조건대로 동작하지만 테스트가 오래된 선택자, 잘못된 검증문, 유효하지 않은 픽스처, 잘못된 순서 또는 부족한 준비 완료 조건을 사용한다. - 구현 원인: 제어 요소가 반응하지 않거나, 상태 또는 탐색이 잘못되었거나, 접근성 회귀가 있거나, 제품 코드 때문에 애플리케이션 요청이 실패하는 등 사용자에게 보이는 동작이 인수 조건을 위반한다. - 환경 원인: 테스트와 구현은 올바를 수 있지만 서비스 중단, 잘못된 자격 증명, 호환되지 않는 브라우저, 누락된 초기 데이터, 잘못된 설정 또는 소진된 자원처럼 필수 전제 조건이 없거나 정상 상태가 아니다. 증거가 혼재하면 서로 경쟁하는 가설을 작성하고 한 번에 하나의 판별 검사를 실행한다. 모든 시간 초과를 테스트 문제로 분류해서는 안 되며, 테스트가 실패했다는 이유만으로 제품 코드를 변경해서도 안 된다. 증거가 가장 가까운 대안 원인을 배제할 때까지 분류를 잠정적인 것으로 유지한다. ## 어서션을 약하게 하지 않고 원인에 맞게 가장 작게 고친다 광범위한 재구성 없이 분류된 원인을 해결하는 수정 방법을 선택한다. 인수 조건과 실패 경로 밖의 기존 사용자 동작을 보존한다. - 테스트 원인이라면 관찰된 브라우저 상태와 모순되는 선택자, 검증문, 픽스처, 동작 순서 또는 준비 완료 조건만 수정한다. - 구현 원인이라면 가능할 때 실패하는 회귀 테스트를 추가하거나 유지한 뒤, 지정된 동작을 복원하는 데 필요한 최소 범위의 제품 로직만 변경한다. - 환경 원인이라면 누락된 전제 조건을 복구하거나 문서화한다. 더 긴 대기 시간, 비활성화된 검증문 또는 무조건 재시도로 문제를 숨겨서는 안 된다. - 고정된 대기 시간보다 가시적인 준비 완료, 요청 완료 또는 안정된 상태와 같은 결정적 신호를 우선한다. - 테스트 용이성을 위한 변경은 사용자에게 중립적이어야 한다. 테스트를 부수적인 배치에 결합하지 말고 안정적인 식별자나 접근 가능한 레이블을 추가한다. 보호된 리소스, 생성된 리소스, 프로덕션 리소스, 파괴적 리소스 또는 자격 증명을 포함한 리소스를 수정하기 전에 중단하고 필요한 권한을 얻는다. 테스트, 기록, 화면 캡처, 픽스처 또는 보고서에 비밀 정보를 절대 노출하지 않는다. ## 같은 시나리오를 다시 실행하고 실패가 이어지면 멈춘다 수정 후에는 동일한 브라우저 조건과 인수 조건으로 정확히 같은 실패 시나리오를 다시 실행한다. 브라우저가 정의된 성공 상태에 실제로 도달하고 테스트 실행기가 숨은 실패를 보고하지 않을 때만 통과로 인정한다. 콘솔과 네트워크 신호가 진단의 일부였다면 원인이 된 오류가 더 이상 나타나지 않는지도 확인한다. 그다음 주변 시나리오, 기능 파일 또는 밀접하게 결합된 테스트 그룹 중 직접 영향을 받는 최소 회귀 검증 범위를 실행한다. 변경의 영향이 넓거나 사용자가 명시적으로 요청한 경우가 아니면 관련 없는 전체 테스트 모음으로 범위를 확대하지 않는다. 재실행이 다른 방식으로 실패하면 추측성 수정을 누적하지 말고 증거 확보와 분류 단계로 돌아간다. 반복 시도 횟수를 제한한다. 같은 접근 방식을 사용한 수정이 두 번 효과가 없으면 진단을 재검토하고 다른 판별 검사를 선택한다. 새로운 증거 없이 세 번 연속 실패하면 코드베이스를 계속 변경하지 말고 중단한 뒤 차단 요인을 보고한다. ## 통과·실패·막힘 중 무엇인지 증거와 함께 먼저 알린다 원래의 브라우저 관찰 가능 인수 조건이 통과하고, 직접 영향을 받는 회귀 검증 범위도 통과하며, 관련된 원인 오류가 남아 있지 않을 때만 성공으로 중단한다. 권한이나 자격 증명이 없거나, 인프라를 사용할 수 없거나, 파괴적 작업이 필요하거나, 안전하게 추론할 수 없는 제품 결정이 필요할 때도 중단한다. 다른 사람이 결과를 검증할 수 있을 만큼 충분한 증거와 함께 다음 내용을 보고한다. - 사용한 시나리오와 브라우저 조건 - 관찰된 실패와 그 분류 - 분류를 뒷받침한 증거 - 적용한 최소 변경 또는 해결되지 않은 전제 조건 - 정확히 다시 실행한 항목과 그 결과 - 남은 위험, 생략한 광범위 검사, 다음에 필요한 작업 통과, 실패 또는 차단 여부를 먼저 밝힌다. 성공 조건이 실제 브라우저에 의존한다면 코드 조사만으로, 통과한 단위 테스트만으로, 또는 모의 문서 객체 모델만으로 완료를 주장해서는 안 된다.