Las pruebas como evidencia ejecutable
Escribe comprobaciones que protejan el comportamiento, revelen los límites y sigan siendo útiles cuando cambie la implementación.
AL TERMINAR, PODRÁS
- Elegir ejemplos significativos y casos límite
- Distinguir pruebas unitarias, de integración y de sistema
- Explicar qué demuestra y qué no demuestra una prueba que pasa
Descripción del diagrama: Afirmación → Preparar; Preparar → Actuar; Actuar → Comprobar; Reloj falso → Preparar (controla el tiempo); Reloj falso → Actuar
Empieza por una afirmación
Una prueba automatizada (test) registra una afirmación sobre el comportamiento y la comprueba automáticamente. «La espera nunca supera los sesenta segundos» es una afirmación útil; «la función auxiliar se llama una vez» quizá solo describe la implementación de hoy.
Prepara una entrada conocida, ejecuta una acción y compara el resultado con una expectativa significativa. Empieza con un ejemplo normal, un caso límite y un caso inválido. Nombra las pruebas según el comportamiento que protegen, para que una falla explique qué garantía pudo romperse.
Una suite en verde es evidencia sobre los casos cubiertos, no una demostración de corrección universal.
def retry_delay(attempt):
return 60 if attempt >= 6 else 2 ** attempt
def test_retry_delay_is_capped():
assert retry_delay(10) == 60
def test_first_retry_delay():
assert retry_delay(0) == 1Prueba en la frontera correcta
Una prueba unitaria comprueba un comportamiento pequeño de forma aislada; una prueba de integración comprueba componentes que colaboran, como el código de acceso a datos con una base de datos real; una prueba de sistema ejercita un flujo completo del usuario.
Cada uno encuentra fallas distintas. Una base de datos simulada (mock) no puede demostrar que tu consulta SQL funciona. Una prueba completa en el navegador puede mostrar que el flujo funciona, pero da poco detalle de diagnóstico cuando falla.
Prefiere la retroalimentación rápida y enfocada, y conserva unas pocas comprobaciones para las integraciones importantes. El equilibrio adecuado depende de los riesgos de tu aplicación.
Controla las fuentes de incertidumbre
El tiempo, el azar, la disponibilidad de la red y el estado compartido pueden volver inestables las pruebas (flaky: a veces pasan y a veces no).
Pasa un reloj como parámetro, fija la semilla de un generador cuando corresponda y aísla los datos de cada prueba. En Relay, un reloj falso hace que una prueba de una política de reintento de sesenta segundos termine al instante. Agrega pruebas de regresión que fallen con un error reproducido y pasen después de corregirlo.
Considera propiedades además de ejemplos: una cola nunca debería devolver más trabajos extraídos con éxito de los que se agregaron. Cuando una prueba falla de forma intermitente, investiga la dependencia oculta en lugar de repetirlo hasta que salga verde.
ERROR FRECUENTE
Una cobertura alta igual puede pasar por alto requisitos incorrectos y aserciones débiles. Mide si los comportamientos importantes están protegidos.
INTÉNTALO TÚ
Escribe pruebas para las esperas de reintento con 0, 1, 5 y 10 intentos, más la política que elijas para entradas inválidas. Explica qué caso detectaría que falta el tope.
Decide en el laboratorio.
El checkpoint de dos preguntas, tus notas y tu progreso guardado están en el laboratorio. Gratis y sin cuenta.
Abrir en el laboratorio ↗CONÉCTALO CON RELAY
Crea pruebas de Relay para el orden FIFO, las colas vacías, los límites de reintento y la disponibilidad de trabajos diferidos con un reloj controlado.