Vorrei rispondere ad alcuni commenti del mio precedente post. Il primo di Claudio Maccari
Nel tuo esempio crei un thread per ogni OrderThread e non credo sia la cosa più efficente da fare. meglio usare ThreadPool.QueueUserWorkItem Io scriverei così all'interno di OrderThread
public void Start()
{
ThreadPool.QueueUserWorkItem(delegate { _broker.PlaceOrder(_order); });
}
ma in questo caso non saprei come scrivere uno unit-test adeguato. tu come faresti ?
Per prima cosa cambiamo l'implementazione della classe OrderThread in modo che utilizzi un ThreadPool:
class OrderThread
{
private readonly IBroker _broker;
private readonly Order _order;
...
Vorrei segnalare il blog Google Testing Blog in particolare dall'ultimo post:
Singletons are nothing more than global state. Global state makes it so your objects can secretly get hold of things which are not declared in their APIs, and, as a result, Singletons make your APIs into pathological liars.
Questo l'ho anche visto quando si abusa dei framework di IoC risalire alle dipendenze di un oggetto diventa un'ardua impresa.
Nel mio precedente post ho affrontato il problema di come sviluppare usando il TDD un'applicazione multithreading.
In questo post, cercherò di approfondire su come testare la sincronizzazione per l'accesso ad una risorsa condivisa.
L'obiettivo che voglio raggiungere è scrivere un test che fallisca se non applico un meccanismo di sincronizzazione (in questo caso la lock) per l'accesso alla risorsa e abbia successo quando viene introdotta la sincronizzazione. Il fatto che il test abbia successo deve essere sistematico e non...