에피소드 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();
위와 같은 브라우저 테스트의 스니펫은 대부분 정확하지 않습니다. 일부 UI가 표시되기 전에 다른 프로세스와 스레드에서 발생해야 하는 많은 이벤트가 있습니다.
다음은 올바른 해결 방법입니다.
SubmitTestPasswordForm(); WaitUntilCredentialPromptVisible();
위의 수정사항은 WaitUntilCredentialPromptVisible()가 실제로 UI를 확인하지 않는다고 가정할 때 올바릅니다.
'포커스 상실' 또는 '창이 포그라운드로 전환됨'과 같은 브라우저 테스트는 외부 UI 이벤트에 의존해서는 안 됩니다. 브라우저 창이 활성 상태일 때만
메시지가 표시되는 구현을 상상해 보세요. 이러한 구현은 올바르지만 실제 창을 확인하면 테스트가 불안정해집니다.
수정 후 단계
테스트가 수정되면 로컬에서 수백 번 실행합니다. Flakiness Portal을 주시하세요.