L'unico modo che conosco per testare un software che utilizza la concomitanza del tipo di blocco è provarlo con prove di stress.
Puoi scrivere test unitari che coprono alcune o anche tutte le operazioni che implicano la concorrenza, ma non hai ancora testato il tuo software, perché i problemi con la concorrenza derivano da interazioni impreviste tra thread che dipendono molto dal timing, e quindi non deterministico.
Quindi, devi scrivere un test che esegue il tuo sistema per ore, sperando che se c'è un problema, si manifesterà.
Naturalmente, il tuo software potrebbe contenere un difetto che si manifesta solo una volta su un milione di operazioni di blocco, nel qual caso, da un punto di vista statistico, non hai praticamente nessuna possibilità di rilevarlo durante i test interni, quindi spedisci il tuo prodotto e migliaia e migliaia di utenti iniziano a utilizzarlo giorno dopo giorno, 24 ore su 24, e il difetto inizia a manifestarsi ogni tanto, il che è un incubo.
Ecco perché il settore si sta allontanando dalla concorrenza del tipo di blocco e utilizza invece altri approcci, come i sistemi share-nothing in cui i thread comunicano tra loro solo tramite code di messaggi, attraverso cui passano solo dati immutabili, quindi che l'unica posizione nell'intero sistema che implica il blocco è costituita da poche istruzioni in una sola classe, la classe della coda dei messaggi. Il grande vantaggio di questi sistemi è che sono testabili, mentre i sistemi concorrenti di tipo lock non sono realmente testabili.
Sono più simili a "stress test e pregare".