Episódio 2:da Vasilii em Munique (maio de 2019)
Episódios anteriores
Os testes instáveis são um problema comum no Chrome. Eles afetam a produtividade de outros desenvolvedores e são desativados com o passar do tempo. Testes desativados significam uma redução na cobertura de testes.
Etapa de triagem
Os PROPRIETÁRIOS dos diretórios são responsáveis por corrigir os testes instáveis. Se você recebeu um bug sobre um teste instável, passe alguns minutos e comente o que deu errado no bug. Se você tiver um teste instável antigo e não tiver certeza do que deu errado, simplesmente a reative. Reatribua o bug assim que possível se ele for claramente um problema em outro componente. Os proprietários desse componente devem ter um bom senso sobre a falha,
Estágio de depuração
Várias sinalizações de linha de comando são úteis para
corrigir testes instáveis. Por exemplo, --enable-pixel-output-in-tests
renderiza a interface real do navegador.
Tenha ferramentas substitutas se o depurador fizer a inconsistência desaparecer. É
possível que o teste nunca seja instável no depurador. Nesse caso, os log statements ou base::debug::StackTrace podem ser úteis.
Tenha em mente os motivos comuns para falhas de EXPECT__*, além de bugs no código de
produção:
- Expectativas incorretas. Por exemplo, página segura significa HTTPS, mas pode ser um localhost.
- Disputas devido a testes que não esperam pelo evento adequado.
[Não teste a implementação][not-implementation], mas o comportamento.
// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();
No futuro, as duas viagens de ida e volta podem mudar para três, o que torna o teste instável. No entanto, apenas o estado do armazenamento é relevante. Em vez disso, use um observador para o armazenamento.
Cuidado com padrões comuns, como os seguintes:
Submit TestPasswordForm(); // Wait until things settle down. RunLoop().RunUntilIdle(); CheckCredentialPromptVisible();
Um snippet de um teste de navegador, como o acima, é quase certamente incorreto. Há muitos eventos que precisam acontecer em diferentes processos e linhas de execução antes que alguma IU apareça.
Confira a seguir uma correção correta:
SubmitTestPasswordForm(); WaitUntilCredentialPromptVisible();
A correção acima está correta, supondo que
WaitUntilCredentialPromptVisible() não verifica a interface.
Os testes de navegador não podem depender de eventos de interface externos, como "foco perdido"
ou "janela ficou em primeiro plano". Imagine uma implementação em que o prompt
apareça somente quando a janela do navegador estiver ativa. Essa implementação
está correta. No entanto, verificar a janela real torna o teste instável.
Estágio pós-correção
Depois que o teste for corrigido, execute-o centenas de vezes localmente. Fique de olho no Flakiness Portal.