에피소드 2: 뮌헨에서 열린 바실리 (2019년 5월)
이전 에피소드
불안정한 테스트는 Chrome에서 흔히 발생하는 문제입니다. 그들은 다른 개발자의 생산성에 영향을 미치고 시간이 지남에 따라 사용 중지됩니다. 테스트를 중지하면 테스트 적용 범위가 줄어듭니다.
분류 단계
디렉터리 소유자는 불안정한 테스트를 수정할 책임이 있습니다. 불안정한 테스트에 관한 버그를 받은 경우 몇 분 정도 시간을 내어 버그에 문제를 주석으로 추가합니다. 오래된 불안정한 테스트가 있고 무엇이 문제인지 명확하지 않으면 테스트를 다시 사용 설정해 보세요. 다른 구성요소의 명백한 문제인 경우 최대한 빨리 버그를 재할당합니다. 해당 구성 요소의 소유자는 실패에 대해 더 나은 판단을 해야 합니다.
디버깅 단계
여러 가지 명령줄 플래그는
불안정한 테스트를 수정했습니다. 예를 들면 다음과 같습니다. --enable-pixel-output-in-tests
실제 브라우저 UI를 렌더링합니다.
디버거로 인해 결함이 사라지는 경우 대체 도구를 사용합니다. 그것은
디버거에서 테스트가 불안정하지 않습니다. 이 경우
문 또는 base::debug::StackTrace를 사용하면 편리합니다.
프로덕션의 버그 외에 EXPECT__* 실패의 일반적인 원인에 유의하세요.
코드:
- 기대치가 잘못됨 (예: 보안 페이지는 HTTPS를 의미하며, 대신 로컬 호스트가 될 수 있음).
- 테스트가 적절한 이벤트를 대기하지 않아 발생한 경합 상태
[구현은 테스트하지 마세요][not-implementation] 하지만 동작은 다음과 같습니다.
// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();
두 번의 왕복이 향후 3회로 변경되어 테스트가 불안정해질 수 있습니다. 그러나 매장 상태만 관련이 있습니다. 대신 있습니다.
다음과 같은 일반적인 패턴에 주의하세요.
Submit TestPasswordForm(); // Wait until things settle down. RunLoop().RunUntilIdle(); CheckCredentialPromptVisible();
브라우저 테스트에서 생성된 위의 스니펫은 거의 확실하게 정확하지 않습니다. 서로 다른 프로세스에서 발생해야 하는 많은 이벤트가 있고 몇 가지 스레드가 있습니다.
올바른 수정사항은 다음과 같습니다.
SubmitTestPasswordForm(); WaitUntilCredentialPromptVisible();
위의 수정사항은
WaitUntilCredentialPromptVisible()는 실제로 UI를 확인하지 않습니다.
'포커스 손실'과 같은 외부 UI 이벤트에 브라우저 테스트가 의존하면 안 됨
또는 '창이 포그라운드가 됨'이 표시됩니다. 프롬프트가 입력 문장의
브라우저 창이 활성 상태일 때만 표시됩니다. 이러한 구현은
맞습니다. 하지만 실제 창을 확인하면 테스트가 불안정해집니다.
사후 수정 단계
테스트가 수정되면 로컬에서 수백 번 실행합니다. 다음 Flakiness Portal.