Nuevo: ¡TestSprite CLI ya está disponible!

No Toda Prueba en Rojo Es un Error Real.

Una prueba que falla una vez y pasa al reintentarla no es prueba de que una función funcione — pero tampoco es prueba de que esté rota. testsprite test flaky <testId> le da a ese fallo una puntuación de estabilidad en lugar de un encogimiento de hombros.

Integrado en el Mismo CLI Que Ya Usas

GitHub ActionsGitLab CIEjecuciones localesBucles de agentes
Reintentar una prueba inestable hasta que pase no arregla nada — solo esconde el ruido hasta que sale caro. Puntúala, no la reintentes sin más.

Guarda lo que Rompiste

testsprite test flaky <testId> ejecuta una pasada de estabilidad y te dice si un fallo es probablemente una regresión real o fragilidad de la prueba — antes de que alguien pierda tiempo persiguiéndolo.

Entiende lo que Quieres

La puntuación de inestabilidad funciona en cualquier prueba — generada o subida vía test code put — así que también aplica a tu suite existente, no solo a las pruebas nuevas.

Valida lo que Tienes

Las puntuaciones de estabilidad vienen de una ejecución repetida real contra tu entorno en producción, no de una suposición heurística de análisis estático.

Sugiere lo que Necesitas

Una prueba que resulta inestable igual recibe un paquete de fallo — para que puedas ver si detrás del ruido hay un problema de tiempos, de selectores, o del entorno.

$ testsprite test flaky TC_checkout_promo
  Running stability pass...
  4/5 runs passed — stability score: 0.80
  → likely flaky, not a regression

$ testsprite test flaky TC_orders_create
  Running stability pass...
  1/5 runs passed — stability score: 0.20
  → likely a real regression

No Gastes un Intento de Corrección en el Problema Equivocado

Un agente —o una persona— que trata cada prueba en rojo como un error real desperdicia ciclos persiguiendo ruido. La puntuación de estabilidad es la diferencia entre "investiga esto" e "ignora esto."

Diseñado para Suites Que Se Han Vuelto Ruidosas

Funciona en Cualquier Prueba

Generada, subida, no importa — test flaky funciona en cualquier ID de prueba de tu proyecto.

Retroalimenta el Bucle

Un agente que revisa resultados de pruebas puede invocar test flaky antes de decidir si un fallo necesita una corrección o solo un reintento.

Versión Comunitaria Gratuita

Ofrece una versión comunitaria gratuita, haciéndonos accesibles para todos.

Se Combina con la Comparación de Ejecuciones

Usa testsprite test diff junto con la puntuación de inestabilidad para ver exactamente qué cambió entre las ejecuciones buenas y la mala.

Con la Confianza de Empresas de Todo el Mundo

"TestSprite ofrece una rica generación de casos de prueba, una estructura clara y un código fácil de leer. También admite la depuración simple en línea con la capacidad de expandirse rápidamente generando nuevos casos de prueba."

"La automatización de TestSprite nos ayuda a reducir toneladas de trabajo manual. Los desarrolladores pueden detectar y resolver errores fácilmente en una etapa más temprana del proceso de desarrollo."

Preguntas Frecuentes

¿Qué mide realmente testsprite test flaky?

Ejecuta la prueba varias veces contra tu entorno en producción y reporta una puntuación de estabilidad — con qué consistencia pasa — en lugar de depender del resultado de una sola ejecución.

¿En qué se diferencia esto de simplemente reintentar la prueba?

Reintentar una vez y quedarte con el resultado que sea no es una puntuación, es una moneda al aire. La puntuación de estabilidad ejecuta suficientes pasadas para darte un número real sobre el que razonar.

¿Esto funciona en pruebas que yo mismo escribí, no solo en las generadas?

Sí — la puntuación de inestabilidad funciona en cualquier prueba de tu proyecto, incluyendo las subidas con test code put.

¿Qué hago con una puntuación de estabilidad baja?

Trátala como una regresión real que vale la pena investigar — obtén el paquete de fallo con test failure get para ver qué pasó en realidad.

¿Y una puntuación de estabilidad alta en una ejecución que aun así falló una vez?

Eso es más probablemente fragilidad de la prueba —tiempos, cambios de selector, entorno— que un error del producto. Vale la pena corregir la prueba, no necesariamente la aplicación.

Conoce la Diferencia Antes de Reaccionar.