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. Afectan la productividad de otros desarrolladores y se inhabilitan con el tiempo. Si inhabilitas las pruebas, la cobertura disminuirá.

Etapa de clasificación

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

Etapa de depuración

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

Ten herramientas de resguardo si el depurador hace desaparecer la fragilidad. Es posible que, en el depurador, la prueba nunca sea inestable. En ese caso, las instrucciones de registro o base::debug::StackTrace pueden ser útiles.

Qué no debes hacer

Ten en cuenta las razones comunes de las fallas de EXPECT__* además de los errores en el código de producción:

  • Expectativas incorrectas (p.ej., una página segura significa HTTPS; puede ser un localhost).
  • Condiciones de carrera debidas a las 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();

Es posible que los dos viajes de ida y vuelta se conviertan en 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 tienda.

Qué no debes hacer

Ten cuidado con los patrones comunes, como los siguientes:

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

Es casi seguro que un fragmento como el anterior de una prueba de navegador sea incorrecto. Hay muchos eventos que deben ocurrir en diferentes procesos y subprocesos antes de que aparezca alguna IU.

La siguiente es una solución correcta:

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

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

Etapa posterior a la corrección

Una vez que se haya corregido la prueba, ejecútala cientos de veces de forma local. Consulta con atención el Portal de inestabilidad.