Come convincere i membri del team dell'esistenza di un "mandelbug"

Se possibile, potrebbe essere necessario dedicare un po 'di tempo a controllare se questo difetto può essere riprodotto inserendo un po' di sonno o blocco nel codice dell'applicazione. Ma non passare troppo tempo. Dato che questo problema è dovuto al multitasto (e anche come hai osservato), l'occorrenza sarà rara.

Il mio consiglio è di non sudare troppo su questo. Continua il tuo lavoro. Ogni volta che incontri questo arresto, aggiorna il rapporto sui bug con lo stack trace, dicendo che si tratta di ripetizione occorrenza e della modifica del proprietario allo sviluppatore della libreria. Lascia che la direzione / il capo decida se aggiustare o meno a seconda della sua frequenza.

Cerca anche di capire la mentalità dello sviluppatore. Hai detto "eccezione web non catturata". Lo sviluppatore in questa fase potrebbe non essere completamente sicuro di quali saranno gli altri effetti della cattura di questo . Quindi lui / lei può essere riluttante a toccare il codice.

Quindi, dai tuoi commenti più o meno chiarificanti, ho capito in questo modo:

Sei sicuro che manchi solo una semplice gestione aggiuntiva delle eccezioni e sai già quale riga di codice nella lib è problematica e come la lib potrebbe essere risolta.

Perché allora non aggiungerai solo poche righe di codice mancanti alla lib, chiederai gentilmente al team di testare la lib con tali modifiche? Assicurati che sia un cambiamento a basso rischio, facile da capire da parte dello sviluppatore che è responsabile della lib. La cosa peggiore che potrebbe accadere è che qualcuno debba ripristinare quel cambiamento nel tuo VCS se la tua correzione causa qualche nuovo comportamento imprevisto.

La maggior parte delle persone è più facile convincere quando il lavoro è già stato fatto. Inoltre, reagiscono meglio su "ecco una soluzione migliorata", contraria a "questo codice è sbagliato, risolvilo in qualche modo".

EDIT: quando il dev ancora si rifiuta di aggiungere quel cambiamento, l'opzione migliore sta cercando di far funzionare il codice problematico all'interno di un'imbracatura di test isolata dove simuli l'errore di rete. Lavorare efficacemente con il codice legacy descrive molte tecniche su come affrontare questo tipo di problemi. Ad esempio, è possibile creare una versione di test della libreria, inclusi solo i moduli e le funzioni problematiche, e creare un "ambiente fittizio" attorno ad esso in cui è possibile simulare la "eccezione di rete" in condizioni controllate. Potrebbe sembrare uno sforzo eccessivo a prima vista, ma una volta che hai un tale ambiente, puoi aggiungere un sacco di test aggiuntivi (e immagino che abbia senso, da quando l'autore della lib si rifiuta di aggiungere gestione delle eccezioni in un posto, ci si dovrebbe aspettare più bug di quel tipo).

Per un bug come questo, il test fuzz automatizzato (chiamato anche test casuale) potrebbe essere utile per provare a riprodurre esso. Questo automatizza il processo di individuazione del bug randomizzando un insieme fisso di parametri (o input) nella cosa che stai testando. Ogni prova, i parametri vengono registrati in un file di registro, inclusi i timestamp, ecc. In modo che quando si verifica l'arresto anomalo è possibile (in teoria) riprodurre semplicemente il test, utilizzando gli stessi parametri, per riprodurlo.

Poiché è automatizzato, il processo di test può eseguire molti test in un breve periodo di tempo. Spesso può essere lasciato in esecuzione durante la notte e al mattino puoi controllare un file di log per vedere se ha riprodotto l'arresto.

The Devil's Advocate suggerisce un altro percorso.

L'altro sviluppatore ha dichiarato, in modo piatto, che non vi è alcun bug lì.

Riesci a trovare un modo per sottolineare l'inferno del suo presunto bug inesistente e causarne il blocco molto più frequentemente?

La traccia dello stack è una chiara dimostrazione che il bug esiste, o almeno esisteva in una certa build. Quello che non hai è la prova che il bug è stato corretto. Sono sciocchi a ignorarlo. Ho avuto errori "impossibili da riprodurre" dopo centinaia di migliaia di tentativi automatizzati su più sistemi che hanno attivato ogni singola volta sul sistema di un cliente.

Ottengo un paio di bug come quello all'anno, la maggior parte senza nemmeno il vantaggio di una traccia dello stack. In quasi tutti i casi, anche se non riuscivo a riprodurlo in anticipo, avrei potuto facilmente effettuare un test automatico per questo una volta risolto.

Ad esempio, alcuni mesi fa ho corretto un errore che si verificava solo quando l'utente digitava più velocemente di 96 parole al minuto. Prima che l'ho risolto, tutto quello che sapevo era che l'errore si era verificato "a volte". Non mi verrebbe mai in mente di scrivere un unit test per una digitazione veloce. Tuttavia, dopo aver conosciuto la causa principale, fare un test per questo è stato banale.

Anche in quei rari casi in cui un bug non può essere riprodotto anche dopo essere stato riparato, puoi chiuderlo tramite l'ispezione del codice.