Tests inestables en Rust

Tuist puede detectar resultados inconsistentes de los tests de Cargo y ayudarte a investigarlos en Tests → Tests inestables.

Cómo funciona la detección de inestabilidad#

Tuist compara ejecuciones de CI en el mismo commit. Un test que pasa en una ejecución y falla en otra puede marcarse como inestable.

Reporta cada ejecución mediante el comando habitual:

Cargo no reintenta automáticamente los tests fallidos. Volver a ejecutar un trabajo de CI en el mismo commit proporciona otro resultado para la detección entre ejecuciones.

Gestión de tests inestables#

Limpieza automática#

La detección y la recuperación se ejecutan a través de la automatización «Detección de tests inestables» del proyecto. Por defecto, la marca de inestabilidad se borra tras 14 días sin volver a activarse. Edita la ventana de recuperación y las acciones en Settings → Automations.

Gestión manual#

Abre Tests → Flaky Tests para inspeccionar el historial de un test. Puedes marcarlo o desmarcarlo manualmente como inestable desde su página de detalles.

Cuarentena y pruebas de estrés#

Silencia u omite un test desde su página de detalles, o configura la cuarentena en Settings → Automations. La siguiente ejecución de tuist cargo test obtiene el estado actual de cuarentena del proyecto:

• Los tests Silenciados siguen ejecutándose y reportan sus resultados reales, pero sus fallos no hacen fallar el comando. Otros fallos de tests, errores de compilación, cierres inesperados y resultados incompletos siguen fallando con normalidad.
• Los tests Omitidos se excluyen de la ejecución y se reportan como omisiones en cuarentena. La coincidencia incluye el paquete, el target, la ruta del módulo de Rust y el nombre del test, por lo que tests con nombres similares permanecen independientes.

El silenciamiento preserva los paquetes y funcionalidades seleccionados del workspace y ejecuta todos los targets seleccionados incluso si un target silenciado falla. La omisión en cuarentena requiere un único paquete seleccionado: usa tuist cargo test -p store en lugar de un comando de workspace con varios paquetes. Tuist rechaza la omisión con varios paquetes porque reducir el alcance del comando puede cambiar las características unificadas de dependencias de Cargo.

La cuarentena también se aplica a las ejecuciones fragmentadas de Cargo. Si Tuist no puede obtener el estado, muestra una advertencia y ejecuta sin cuarentena; los fallos no se suprimen. Para ejecutar deliberadamente sin cuarentena:

La aplicación requiere harnesses estándar de libtest y la captura de la salida predeterminada. Los comandos con salida silenciosa, detallada, en formato alternativo o sin capturar fallan cuando es necesario aplicar la cuarentena. Selecciona un paquete exacto del workspace con -p <package> si la atribución del target es ambigua. No se admiten harnesses personalizados, patrones glob para nombres de paquetes/targets ni selecciones de paquetes sin resolver. Los doctests también pueden silenciarse u omitirse, pero el filtrado de tests de Rustdoc no puede distinguir cada posible par de nombres de ejemplos. Si omitir un ejemplo también omitiría un ejemplo habilitado, o una exclusión parcial de doctests usa --exact, Tuist falla con un diagnóstico en lugar de ejecutar el ejemplo omitido u omitir silenciosamente tests habilitados; usa la anulación anterior mientras investigas.

Tuist no realiza pruebas de estrés de nuevos tests de Cargo. Usa un filtro de tests de Cargo para repetir un test fallido mientras lo investigas:

Notificaciones de Slack#

Configura alertas de tests inestables de Slack para notificar a tu equipo cuando un test se vuelva inestable.