Supponiamo che tu abbia una funzione f che è o contiene una sezione critica. Come testare l'unità che solo un thread può eseguirlo contemporaneamente, che non ha condizioni di competizione e che non causa un deadlock, ecc ...?
Supponiamo che tu abbia una funzione f che è o contiene una sezione critica. Come testare l'unità che solo un thread può eseguirlo contemporaneamente, che non ha condizioni di competizione e che non causa un deadlock, ecc ...?
Non puoi. I test possono solo dimostrare che non hai trovato bug, non che nessuno esiste, e in presenza di codice multi-thread, direi che è quasi inutile. Non è possibile verificare come si comporta la funzione quando il sistema operativo lo modifica o mette in pausa l'esecuzione o uno qualsiasi di mille eventi esterni che possono influire sulla pianificazione del thread e sul suo comportamento.
Devi, almeno in modo informale, dimostrare la funzione corretta.
Non puoi fare un test "strong", ma puoi mitigare il rischio eseguendo un test "debole".
Parametrizza f per prendere qualche altro codice se passato. Poi nel test, passa il codice per un contatore di thread, un sonno e un'affermazione che il contatore di thread non ha mai avuto sopra 1. Quando eseguivo il test userei 5 -10 discussioni. Ristrutturerei anche una funzione senza una sezione critica e assicurarmi che il contatore dei thread fosse al di sopra 1. L'idea sarebbe di assicurarsi che la serializzazione fosse solo il risultato della sezione critica.
Aggiungi addormenta intorno alle operazioni entro f e aggiungi un parametro per permetterti di controllarne la lunghezza. È quindi possibile eseguire il test dell'unità come normale, ma con diversi schemi di pianificazione.
Il TDD è inutile negli scenari multi-thread. Non testate la sicurezza del filo, lo dimostrate o contro-provate, dolorosamente ...
Leggi altre domande sui tag unit-testing multithreading