AntonioGanci

Scrivere uno unit test per l'accesso esclusivo ad una risorsa condivisa da diversi thread - Alcune considerazioni

Antonio Ganci — Sat, 23 Aug 2008 09:40:30 GMT

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;

        private Thread _thread;

        public OrderThread(IBroker broker, Order order)

            _broker = broker;

            _order = order;

        public bool IsWaiting

get

                if (_thread == null) return false;

                return (_thread.ThreadState & ThreadState.WaitSleepJoin) > 0;

        public void Start()

            ThreadPool.QueueUserWorkItem(delegate { PlaceOrder(); });

        private void PlaceOrder()

            _thread = Thread.CurrentThread;

            _broker.PlaceOrder(_order);

Ho dovuto modificare l'implementazione della property IsWaiting perchè i thread creati dal ThreadPool sono Background thread.

Ora lanciamo il test che è rimasto uguale rispetto al precedente post. L'output generato è il seguente:

TestCase 'OrderThreadTests.Access_To_The_Broker_Should_Be_Synchronized' failed: Equal assertion failed: [[1]]!=[[2]]

In pratica entrambi i thread sono all'interno del metodo PlaceOrder del Broker! Abbiamo una race condition. Questo è normale perchè non abbiamo sincronizzato l'accesso al Broker.

Modifichiamo quindi il metodo privato PlaceOrder aggiungendo una lock:

        private void PlaceOrder()

            _thread = Thread.CurrentThread;

            lock(_broker)

                _broker.PlaceOrder(_order);

Ora rilanciamo il test:

[success] OrderThreadTests.Access_To_The_Broker_Should_Be_Synchronized

Ed ecco che abbiamo cambiato l'implentazione della classe OrderTest senza modificare il test. Ci si potrebbe chiedere perchè non ho utilizzato subito un ThreadPool, il motivo è che nell'applicazione questi thread seguono anche lo stato dell'ordine ed hanno quindi una vita molto lunga (un ordine può essere eseguito dopo qualche ora che è stato immesso) e mi serviva avere un riferimento al thread per sincronizzarli tra di loro.

Alcune considerazioni sullo unit testing per il multithreading:

Lo unit test NON garantisce l'assenza di problemi di sincronizzazione come in generale non garantisce l'assenza di bug. In questo caso però modificando l'implementazione con quella proposta di Claudio ha fatto subito emergere il problema di essersi dimenticato il lock

Il TDD in questi casi serve soprattutto a far emergere un'architettura facilmente testabile
Il Multithreading aggiunge molta complessità al codice questo rende difficile anche la scrittura dei test i quali potrebbero dipendere dal pc su cui girano perchè a chi li ha scritti è sfuggita qualche condizione di concorrenza.

Vorrei infine segnalare il post TotT: Sleeping != Synchronization del Google Testing Blog che tratta lo stesso argomento, il codice è scritto in ruby ma non dovrebbero esserci molte difficoltà a comprenderlo.

Google Testing Blog

Antonio Ganci — Mon, 18 Aug 2008 06:54:46 GMT

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.

Come scrivere uno unit test per controllare l'accesso esclusivo ad una risorsa condivisa da diversi thread

Antonio Ganci — Sun, 17 Aug 2008 10:46:26 GMT

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 deve esserci nessun elemento di casualità come l'ordine di schedulazione la velocità del processore.

Vediamo di descrivere lo scenario. La risorsa condivisa è il Broker la cui responsabilità è quella di immettere sul mercato azionario un ordine di acquisto o vendita di azioni. La classe Broker implementa la seguente interfaccia:

    interface IBroker

        void PlaceOrder(Order order);

La classe Order che non riporterò contiene i dati necessari per immettere l'ordine come il prezzo, la quantità di azioni, ecc.

L'ultimo elemento di questo scenario è la classe OrderThread, la sua responsabilità è quella di eseguire il metodo PlaceOrder in un thread creato da lei.

    class OrderThread

        private readonly IBroker _broker;

        private readonly Order _order;

        public OrderThread(IBroker broker, Order order)

            _broker = broker;

            _order = order;

        public void Start()

            Thread thread = new Thread(PlaceOrder);

            thread.Start();

        private void PlaceOrder()

            _broker.PlaceOrder(_order);

Come si può notare alla chiamata PlaceOrder non viene usato nessun meccanismo di sincronizzazione. Quindi due istanze di OrderThread che utilizzino lo stesso broker potrebbero chiamare contemporaneamente il metodo PlaceOrder dando luogo ad una race condition. Vogliamo scrivere un test che abbia successo se la race condition non possa verificarsi e fallisca altrimenti.

Per ottenere il risultato scriviamo un'implementazione dell'interfaccia IBroker pilotabile dal nostro test che ci permetta di simulare lo scenario in cui due OrderThread cerchino di chiamare contemporaneamente il metodo PlaceOrder.

    class SleepingBroker : IBroker

        readonly ManualResetEvent _resetEvent = new ManualResetEvent(false);

        public int CallingPlaceOrderCount { get; set;}

        public void PlaceOrder(Order order)

            CallingPlaceOrderCount++;

            _resetEvent.WaitOne();

            CallingPlaceOrderCount--;

        public void WakeUp()

            _resetEvent.Set();

Il metodo SleepingBroker.PlaceOrder ci permette di far durare la chiamata a PlaceOrder il tempo necessario per creare una race condition. Se il valore della property CallingPlaceOrderCount è maggiore di uno significa che più di un trade sta usando il Broker e quindi il test deve fallire.

Proviamo a questo punto a scrivere il test:

        [Test]

        public void Access_To_The_Broker_Should_Be_Synchronized()

            Order order1 = new Order();

            Order order2 = new Order();

            SleepingBroker broker = new SleepingBroker();

            OrderThread thread1 = new OrderThread(broker, order1);

            OrderThread thread2 = new OrderThread(broker, order2);

            thread1.Start();

            thread2.Start();

            Assert.AreEqual(1, broker.CallingPlaceOrderCount);

            broker.WakeUp();

In questo test abbiamo creato due OrderThread che utilizzano lo stesso Broker (in questo caso SleepingBroker). I due thread vengono fatti partire e controlliamo che effettivamente solo uno sia all'interno del metodo PlaceOrder.

Il test apparentemente corretto in realtà contiene un errore concettuale. L'errore è che potrebbe fallire o avere successo in maniera del tutto casuale perchè dipende dalla velocità di creazione ed esecuzione dei thread al momento in cui si fa la Assert.

Il valore di CallingPlaceOrderCount potrebbe quindi essere 0, 1 oppure due. Zero nel caso in cui entrambi i thread siano stati creati ma al momento della Assert la chiamata a PlaceOrder non sia ancora avvenuta. Uno nel caso che uno dei due sia entrato nella PlaceOrder. Due nel caso in cui entrambi siano nella PlaceOrder.

Per come abbiamo scritto il test questo non è determinabile. Quindi modifichiamolo sincronizzandoci nel modo corretto. Per far questo ci viene in aiuto la property ThreadState, nel caso in cui il valore è impostato su WaitSleepJoin come descritto nella MSDN:

The thread is blocked. This could be the result of calling Thread..::.Sleep or Thread..::.Join, of requesting a lock — for example, by calling Monitor..::.Enter or Monitor..::.Wait — or of waiting on a thread synchronization object such as ManualResetEvent.

Quindi se entrambi i thread sono in WaitSleepJoin siamo sicuri di poter eseguire la Assert su CallingPlaceOrderCount nel momento corretto.

Per controllare lo stato del thread Aggiungiamo la Property IsWaiting alla classe OrderThread.

    class OrderThread

        private readonly IBroker _broker;

        private readonly Order _order;

        private Thread _thread;

        public OrderThread(IBroker broker, Order order)

            _broker = broker;

            _order = order;

        public bool IsWaiting

get

                if (_thread == null)

                    return false;

                return _thread.ThreadState == ThreadState.WaitSleepJoin;

        public void Start()

            _thread = new Thread(PlaceOrder);

            _thread.Start();

        private void PlaceOrder()

            _broker.PlaceOrder(_order);

Quindi ora aggiungiamo il codice nel test che attenda che per entrambi i Thread IsWaiting sia a true.

        [Test]

        public void Access_To_The_Broker_Should_Be_Synchronized()

            Order order1 = new Order();

            Order order2 = new Order();

            SleepingBroker broker = new SleepingBroker();

            OrderThread thread1 = new OrderThread(broker, order1);

            OrderThread thread2 = new OrderThread(broker, order2);

            thread1.Start();

            thread2.Start();

            while(!thread1.IsWaiting || !thread2.IsWaiting)

                Thread.Sleep(0);

            Assert.AreEqual(1, broker.CallingPlaceOrderCount);

            broker.WakeUp();

In questo modo abbiamo tolto l'elemento di casualità spiegato prima. Se non modifichiamo il codice della classe OrderThread il test fallirà in modo sistematico:

TestCase 'OrderThreadTests.Access_To_The_Broker_Should_Be_Synchronized' failed: Equal assertion failed: [[1]]!=[[2]]

Aggiungiamo a questo punto la lock prima della chiamata di PlaceOrder nella classe OrderThread:

        private void PlaceOrder()

            lock(_broker)

                _broker.PlaceOrder(_order);

Proviamo ora a lanciare nuovamente il test ed ecco finalmente la conferma che i due thread sono sincronizzati:

Found 1 tests
[success] OrderThreadTests.Access_To_The_Broker_Should_Be_Synchronized

Il motivo per cui il test passa è che in questo caso sono entrambi in waiting ma uno è all'interno del metodo PlaceOrder mentre l'altro è fermo sulla lock.

L'esempio che ho fatto si può adattare facilmente anche ad altri scenari, in quanto cambieranno gli attori, ma i concetti sono gli stessi.

Feedback?

How I got Started in Software Development

Antonio Ganci — Thu, 17 Jul 2008 20:36:48 GMT

Dopo la provocazione di Gianluca non potevo esimermi dal rispondere ;-).

A quale età hai cominciato a programmare?

Quinta elementare: lessi un libro della casa editrice Jackson (qualcuno la ricorda?) la quale introduceva agli elementi di base sulla programmazione

Come hai cominciato a programmare?

Su un foglio di carta. Scrivevo il listato rigorosamente in basic e poi lo simulavo manualmente.

Qual’è stato il tuo primo linguaggio di programmazione?

Basic del Commdore64.

Qual’è stato il primo programma vero che hai scritto?

Un gestionale in Foxpro per il mio professore di elettronica in quinta superiore.

Quali linguaggi hai usato da quando hai cominciato a programmare?

Turbo Pascal, Basic (nelle varie incarnazioni GWBASIC, QuickBasic, ...), Assembler, C, C++, Prolog, VB, C# e tanti altri che nemmeno ricordo

Quando è stato il tuo primo vero lavoro da programmatore?

Vedi sopra

Con il senno di poi, rifaresti lo stesso il programmatore? Ricominceresti a programmare?

Certamente. What else? :-)

Se ci fosse una cosa che hai imparato nella tua carriera e che vorresti dire ai giovani programmatori, cosa diresti?

Studiate, leggete e soprattutto imparate dal codice scritto da altri. Un'ultima cosa è grazie ai clienti se pagate l'affitto quindi non trattateli troppo male.

Qual’è la cosa più divertente che hai programmato?

Alcuni videogiochi realizzati con il mitico S.E.U.C.K. (anche se non si può dire verà programmazione) e la gestione multiplayer di un videogioco tramite le DirectPlay

Chi tirare in ballo ora?

Tell, Don't Ask - alcuni spunti di riflessioni su come migliorare il disegno delle proprie applicazioni

Antonio Ganci — Thu, 17 Jul 2008 20:00:02 GMT

Ho letto il post The Flawed Theory Behind Unit Testing di Michael Feathers e mi ha fornito alcuni spunti interessanti di riflessione. In particolare:

John Nolan, gave his developers a challenge: write OO code with no getters. Whenever possible, tell another object to do something rather than ask. In the process of doing this, they noticed that their code became supple and easy to change.

Ho rivolto la questione al team con cui sto lavorando ed il coach ha posto la seguente domanda:

Una cosa che continuo a chiedermi a proposito dell "tell, don't ask" è la maniera in cui vengono normalmente realizzate le pagine web: tu hai un template a cui passi oggetti a cui chiedi varie informazioni. E' tutto un "ask, don't tell", che fa sì che gli oggetti che passi alla view siano, alla fine, oggetti di dominio, i quali finiscono per essere poco più che contenitori di dati estratti dal DB. Questo è quello che si fa di solito. La domanda che vi pongo è: come si potrebbe fare altrimenti? A partire dalla view: come puoi fare una view che applica il "tell, don't ask"?

Un altro link interessante su questo concetto è Tell, Don't Ask.

Alla domanda di prima non ho una risposta, ma ci sto riflettendo. Inoltre voglio approfondire l'argomento e verificare se l'approccio è efficace. Questo implica ragionare con gli oggetti in funzione di cosa fanno piuttosto che dipendere da quale stato siano.

In termini di TDD significa prediligere i test d'interazione piuttosto che quelli di stato e quindi l'utilizzo intensivo dei mock objects.

Cosa ne pensate?

Fino a che punto siamo disposti a cambiare nel lavoro?

Antonio Ganci — Wed, 18 Jun 2008 13:05:51 GMT

A parole tutti vorremmo cambiare, è un mantra, che spesso si sente in tv soprattutto in periodo elettorale. Sembrerebbe che la natura umana stia a suo agio nel cambiamento.
In realtà le cose funzionano in maniera completamente diversa, noi per natura, non vogliamo cambiare; il cambiamento ci costa fatica e per istinto cerchiamo di osteggiarlo.
Riportando queste divagazioni al nostro mestiere di sviluppatori, magari con qualche anno di lavoro alle spalle, proviamo a rispondere alla domanda: Fino a che punto siamo disposti a cambiare? E con cambiare intendo:

Metodo di approccio allo sviluppo software (ad es: passare da Waterfall ad xp? e viceversa?)
Tecnologia (sviluppo da diversi anni in .NET passerei a java? e viceversa?)
Sistema Operativo (ho sempre usato windows xp, passerei a Vista e a linux? e viceversa?)
Altro?

Quale la cosa che non cambierei per nulla al mondo? (a meno di eventi che ci costringano senza alternative).

A questo proposito segnalo l'interessante post sul cambiamento che aveva segnalato lorenzo in questo post e che in parte ha ispirato questo post.
Cosa ne pensate?

Object-Oriented Reengineering Patterns

Antonio Ganci — Mon, 09 Jun 2008 18:18:34 GMT

Segnalo il libro Object-Oriented Reengineering Patterns scaricabile gratuitamente come pdf.

Non ne ho ancora terminato la lettura, ma per ora mi ha fornito alcuni spunti interessanti.

Affronta il problema di reingegnerizzare un software esistente e fornisce come strumenti una serie di pattern.

Usare il Test Driven Development per progettare applicazioni multithreading - Un esempio concreto

Antonio Ganci — Fri, 06 Jun 2008 11:29:09 GMT

Il multithreading aggiunge complessità al design di un'applicazione. Occorre prestare attenzione alle differenti problematiche legate alla sincronizzazione, race condition, ecc.

In questi giorni sto realizzando un'applicazione in cui devo salvare dei messaggi di log su un database e per non rallentare il chiamante la scrittura sul database avviene in modo asincrono.

Voglio realizzare questa funzionalità in TDD e riporto qui i passi che ho effettuato e la soluzione trovata. Per ogni test scriverò prima il codice del test, introducendo classi e metodi necessari a descrivere lo scenario che sto testando, successivamente scriverò l'implementazione minima per far compilare il test ed infine modificherò il codice per farlo passare.

Partiamo dal LogWriter:

 public interface ILogWriter
 {
     void Write(Log log);
 }

L'implementazione concreta di questa interfaccia salva sul database i dati contenuti nella classe Log. La classe che realizzerò in TDD deve chiamare in modo asincrono il metodo Write.

Non utilizzerò librerie di mocking e scriverò delle classi stub che simuleranno i vari scenari da testare; questo renderà più semplice la comprensione del codice. Il primo stub che useremo conta quante volte viene chiamato il metodo Write e salva l'ultimo parametro con cui è stato chiamato:

class LogWriterForTest : ILogWriter
{
    public int WriteCallCount = 0;
    public Log Log = null;
    public void Write(Log log)
    {
        WriteCallCount++;
        Log = log;
    }
}

Il test controlla che quando viene accodato un log viene chiamato il metodo Write:

 
[Test]
public void When_Enqueue_A_Log_The_LogWriter_Is_Invoked()
{
    Log log = new Log();
    LogWriterForTest writer = new LogWriterForTest();
    LogThread thread = new LogThread(writer);
    thread.Enqueue(log);
    Assert.AreEqual(1, writer.WriteCallCount);
    Assert.AreEqual(log, writer.Log);
}

Per far passare il test non è necessario che il metodo Enqueue chiami il metodo Write in modo asincrono, questo sarà compito del prossimo test. Questo concetto è importante nel TDD e lo ribadisco: scrivere solo il codice indispensabile a far passare il test anche se non contiene ancora le funzionalità che effettivamente ci servono. Questo ci consente di ridurre al minimo la complessità del codice e dell'architettura e di arrivare alla soluzione in modo incrementale.

Il primo passo da fare ora è quello di scrivere il codice minimo per compilare, ma che non basta per far passare il test:

             public class             LogThread
             {
     public              LogThread(ILogWriter             writer)
     {
     }
              
     public              void Enqueue(Log log)
     {
     }
             }

Se eseguo ora il test ottengo il messaggio: Expected: 1 But was: 0, in quanto il metodo Write non è stato chiamato; aggiungiamo quindi la chiamata:

             public class             LogThread
             {
     private             readonly              ILogWriter _writer;
              
     public              LogThread(ILogWriter             writer)
     {
         _writer =             writer;
     }
              
     public              void Enqueue(Log log)
     {
         _writer.Write(log);
     }
             }

Rilanciamo il test che passa con successo.

Passiamo al prossimo scenario: quando viene chiamata la Write il metodo Enqueue la esegue in modo asincrono. Ci serve un meccanismo di sincronizzazione che ci permetta di bloccare il metodo write e sbloccarlo successivamente con un comando; creiamo a questo scopo un nuovo stub:

         class              ManualResetLogWriter : ILogWriter
             {
     public              int WritingCount = 0;
     public              Log Log =             null;
     public              readonly ManualResetEvent             ResetEvent =              new ManualResetEvent(false);
     public              void Write(Log log)
     {
         WritingCount++;
         Log =             log;
         ResetEvent.WaitOne();
                 WritingCount--; 
     }
             }

Quando chiamiamo il metodo Write del ManualResetLogWriter l'esecuzione si blocca sull'istruzione ResetEvent.WaitOne() fin quando da un altro thread non viene chiamato il metodo Set della classe del framework .NET ManualResetEvent.

La classe ManualResetLogWriter è utile nel prossimo test, in cui voglio verificare che le chiamate al metodo Write avvengono in modo asincrono. Sarà necessario modificare il metodo Enqueue affinché invochi il metodo write in un theread dedicato, evitando così che l'esecuzione dell'Enqueue si blocchi sull'istruzione WaitOne. Verifichiamolo:

             [Test]
             public void             The_Calls_To_The_Writer_Are_Asynchronous()
             {
     Log              log = new             Log();
     ManualResetLogWriter             writer = new             ManualResetLogWriter();
     LogThread             thread = new             LogThread(writer);
     thread.Enqueue(log);
    while(writer.WriteCallCount == 0)
    {
       Thread.Sleep(0);  
    }

 
     Assert.AreEqual(1,              writer.WriteCallCount);
    writer.ResetEvent.Set();
    Assert.AreEqual(log,             writer.Log);
             }

Se eseguiamo il test con l'implementazione attuale della Enqueue vediamo che il test si blocca sull'istruzione: thread.Enqueue(log). Modifichiamo il codice in modo da far passare questo secondo test:

public class LogThread
{
    private readonly ILogWriter _writer;
 
    public LogThread(ILogWriter writer)
    {
        _writer = writer;
    }
 
   public void Enqueue(Log log)
    {
        Thread thread = new Thread(
        delegate()
        {
            _writer.Write(log);
        });
        thread.Start();
    }
}

Per maggiore compattezza del codice la chiamata _writer.Write(log) è stata fatta all'interno di un anonymous method.

Rieseguiamo il test che ora passa.

Chiaramente non abbiamo ancora finito, perchè due thread in contemporanea potrebbero eseguire la Write creando una Race Condition (o corsa critica in italiano).

Il prossimo test si occuperà proprio di testare che non ci sia una race condition, cioè dobbiamo creare uno scenario in cui il test fallisce nel caso in cui più thread eseguono contemporaneamente il metodo Write. Scriviamo il test e poi commentiamolo un pezzo per volta:

[Test]
public void Two_Logs_Enqueued_Are_Served_One_At_Time()
{
    ManualResetLogWriter writer = new ManualResetLogWriter();
    LogThread thread = new LogThread(writer);
 
    Log log1 = new Log();
    thread.Enqueue(log1);
    while (writer.WritingCount < 1)
    {
        Thread.Sleep(0);
    }
 
    Log log2 = new Log();
    thread.Enqueue(log2);
    while(thread.RunningThreadCount < 2)
    {
        Thread.Sleep(0);
    }
 
    Assert.AreEqual(1, writer.WritingCount);
 
    writer.ResetEvent.Set();
    while (writer.WritingCount > 0)
    {
        Thread.Sleep(0);
    }
}

Nel codice del test precedente ho usato più volte la chiamata Thread.Sleep(0), il metodo Sleep interrompe il thread corrente per x millisecondi, se invece viene passato zero si permette al thread corrente di essere sospeso; questo per evitare di bloccare il PC con CPU al 100% nel caso in cui il test si blocchi in uno dei cicli while.

Il primo ciclo while attende che il primo thread sia fermo all'istruzione ResetEvent.WaitOne del ManualResetLogWriter.

Viene successivamente accodato il secondo log (variabile log2); ci serve quindi un meccanismo che mi permetta di verificare che i thread in esecuzione siano effettivamente due. Per questo scopo introduciamo, per ora solo nel codice del test, la property RunningThreadCount ed aspettiamo che raggiunga il valore 2.

Segue la Assert la quale assume che ci sia un solo thread in scrittura mentra l'altro è in attesa (ricordo che lo scopo é quello di far si che il metodo Write venga eseguito in mutua esclusione).

Il test termina sbloccando la Write tramite l'istruzione writer.ResetEvent.Set() ed infine attendiamo che entrambi i thread siano terminati.

Aggiungiamo la property RunningThreadCount alla classe LogThread:

public class LogThread
{
    private readonly ILogWriter _writer;
    private int     _runningThreadCount = 0;
 
    public LogThread(ILogWriter writer)
    {
        _writer = writer;
    }
 
    public int     RunningThreadCount { get { return     _runningThreadCount; } }
 
    public void Enqueue(Log log)
    {
        Thread thread = new Thread(
        delegate()
        {
                 _runningThreadCount++;
            _writer.Write(log);
                 _runningThreadCount--;
        });
        thread.Start();
    }
}

Eseguendo il test si nota che la assert fallisce in quanto tutte e due i thread eseguono il metodo Write. Dobbiamo ora inserire un meccanismo di sincronizzazione, useremo l'istruzione lock:

    public void Enqueue(Log log)
    {
        Thread thread = new Thread(
        delegate()
        {
                 _runningThreadCount++;
            lock(_writer)
            {
                _writer.Write(log);
            }
                 _runningThreadCount--;
        });
        thread.Start();
    }

Ora rilanciamo il test il quale passerà con successo.

A qualcuno potrà sembrare strano che sia stata aggiunta la property RunningThreadCount, in quanto viene usata solo dal test. Questa pratica però è piuttosto comune nel TDD e capita spesso che queste funzionalità, aggiunte solo per poter testare la classe, tornino utili in seguito anche nel codice di produzione.

Se il metodo Write sollevasse un'eccezione la property RunningThreadCount non verrebbe decrementata. Creiamo un nuovo stub il quale sollevi un eccezione:

class ExceptionRaiseLogWriter : ILogWriter
{
    public bool IsWriting = false;
    public void Write(Log log)
    {
        IsWriting = true;
        throw new ArgumentException();
    }
    }
}

Ed il test che verifichi che effettivamente venga descrementata la property:

public void When_The_Writer_Throws_An_Exception_The_QueueLength_Is_Decreased()
{
    ExceptionRaiseLogWriter writer = new ExceptionRaiseLogWriter();
    LogThread thread = new LogThread(writer);
    thread.Enqueue(new Log());
    while(!writer.IsWriting)
    {
        Thread.Sleep(0);
    }
    while(thread.RunningThreadCount > 0)
    {
        Thread.Sleep(0);
    }
}

Proviamo ad eseguirlo: il test si blocca all'interno dell'ultimo while.

Per far passare il test aggiungiamo un try / finally al metodo Enqueue della classe LogThread:

        public void Enqueue(Log log)
        {
            Thread thread = new Thread(
            delegate()
            {
                      _runningThreadCount++;
                try
                {
                    lock (_writer)
                    {
                        _writer.Write(log);
                    }
                }
                finally
                {
                          _runningThreadCount--;
                }
            });
            thread.Start();
        }

A questo punto anche questo test è a posto.

Mancano ancora altre cose, come la gestione delle eccezioni, ecc. ma credo che il modo di procedere ora sia chiaro.

Un altro test interessante da sviluppare è quello relativo alla gestione delle richieste secondo una politica FIFO mediante una coda, vale a dire che la prima richiesta accodata sia effettivamente la prima ad essere eseguita, mentre nell'implentazione derivata dai test finora scritti l'ordine di scrittura dipende da quale thread viene sbloccato prima e quindi non è deterministico.

Se avete suggerimenti, consigli o segnalazioni di errori scrivetemeli nei commenti.