Chromium Chronicle #2: Como combater os incômodos no teste

Episódio 2: por Vasilii em Munique (maio de 2019)
Episódios anteriores

Testes instáveis são um problema comum no Chrome. Eles impactam a produtividade de outros desenvolvedores e são desativados ao longo do tempo. Testes desativados significam diminuir a cobertura dos 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 relacionado a um teste instável, dedique alguns minutos e comente o que deu errado no bug. Se você tem um teste instável e não estiver claro o que deu errado, tente simplesmente reativar o teste. Reatribua o bug assim que possível se claramente for um problema em outro componente. Os proprietários desse componente precisam ter um bom julgamento sobre a falha,

Estágio de depuração

Algumas sinalizações de linha de comando são úteis para corrigindo testes instáveis. Por exemplo, --enable-pixel-output-in-tests. processará a interface real do navegador.

Tenha ferramentas substitutas se o depurador fizer a inconsistência desaparecer. Está é possível que, no depurador, o teste nunca seja instável. Nesse caso, registre instruções ou base::debug::StackTrace podem ser úteis.

O que não fazer

Lembre-se dos motivos comuns para falhas de EXPECT__*, além dos bugs na produção código:

  • Expectativas incorretas. Por exemplo, página segura significa HTTPS (pode ser um localhost).
  • Condições da corrida devido a testes que não aguardam o 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();

As duas viagens de ida e volta podem mudar para três no futuro, tornando o teste instável. No entanto, apenas o estado da loja é relevante. Em vez disso, use um observador para o loja on-line.

O que não fazer

Cuidado com padrões comuns, como os seguintes:

Submit TestPasswordForm();
// Wait until things settle down.
RunLoop().RunUntilIdle();
CheckCredentialPromptVisible();

Um snippet como o exemplo acima de um teste de navegador está quase sempre incorreto. Há muitos eventos que devem acontecer em diferentes processos e linhas de execução antes que a interface apareça.

O que fazer

Confira a seguir a correção correta:

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

A correção acima está correta, supondo que O app WaitUntilCredentialPromptVisible() não verifica a interface. Os testes de navegador não podem depender de eventos de interface externos, como "foco perdido". ou "a janela ficou em primeiro plano". Imagine uma implementação em que o comando aparece somente quando a janela do navegador está ativa. Essa implementação está correto. 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 Portal Flakiness (link em inglês).