Chromium Chronicle n.° 2: Cómo combatir la fragilidad de las pruebas

Episodio 2: de Vasilii en Múnich (mayo de 2019)
Episodios anteriores

Las pruebas inestables son un problema común en Chrome. Ellas afectan la productividad de otros desarrolladores y se inhabilitan con el tiempo. Si inhabilitas las pruebas, disminuirá la cobertura de la prueba.

Etapa de clasificación

Los PROPIETARIOS de los directorios son responsables de corregir sus pruebas inestables. Si recibiste un error por una prueba inestable, dedica unos minutos y comentar qué salió mal en el error. Si tienes una prueba inestable antigua y no está claro qué salió mal, intenta solo volver a habilitar la prueba. Reasigna el error lo antes posible si claramente es un problema en otro componente. Los propietarios de ese componente deberían tener un mejor juicio sobre la falla

Etapa de depuración

Varias marcas de línea de comandos son útiles solucionar pruebas inestables. Por ejemplo, --enable-pixel-output-in-tests. renderizará la IU real del navegador.

Usa herramientas de resguardo si el depurador hace desaparecer los puntos débiles. Es es posible que, en un depurador, la prueba nunca sea inestable. En ese caso, registra sentencias o base::debug::StackTrace pueden ser útiles.

Qué no debes hacer

Ten en cuenta los motivos comunes por los que falla EXPECT__*, además de los errores en producción código:

  • Expectativas incorrectas (p.ej., página segura significa HTTPS; puede ser un localhost).
  • Condiciones de carrera debido a pruebas que no esperan el evento adecuado

[No pruebes la implementación][not-implementation], sino el comportamiento.

// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();

Los dos recorridos de ida y vuelta pueden cambiar a tres en el futuro, lo que hará que la prueba sea inestable. Sin embargo, solo es relevante el estado de la tienda. En su lugar, usa un observador para la en una tienda física.

Qué no debes hacer

Ten cuidado con los patrones comunes, como los siguientes:

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

Un fragmento como el anterior de una prueba de navegador es casi seguro que es incorrecto. Hay muchos eventos que deberían ocurrir en diferentes procesos y subprocesos antes de que aparezca alguna IU.

Qué debes hacer

La siguiente es una solución correcta:

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

La corrección anterior es correcta bajo el supuesto de que WaitUntilCredentialPromptVisible() no verifica la IU. Las pruebas del navegador no deben depender de eventos de IU externos como “enfoque perdido”. o "la ventana se convirtió en primer plano". Imagina una implementación en la que la instrucción solo aparece cuando la ventana del navegador está activa. Esta implementación sería correcto; sin embargo, comprobar la ventana real hace que la prueba sea inestable.

Etapa posterior a la solución

Una vez que se corrija la prueba, ejecútala cientos de veces de forma local. Presta atención a las Portal de vulnerabilidades.