Extreme Programming

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?

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.

Un esempio concreto di sviluppo di una GUI in TDD: La gestione dei pulsanti OK e Cancel (Parte prima)

Antonio Ganci — Wed, 07 Mar 2007 08:17:00 GMT

Continua l'implentazione del Model View Presenter utilizzando il TDD (Test Driven Development), in questi post affronteremo la gestione del click sui pulsanti Ok e Cancel.

Un esempio concreto di sviluppo di una GUI in TDD (Terza ed ultima parte)

Antonio Ganci — Sun, 04 Mar 2007 14:35:00 GMT

Ecco la terza ed ultima parte di un caso reale di implementazione di MVP in .NET tramite il TDD

Un esempio concreto di sviluppo di una GUI in TDD (Seconda parte)

Antonio Ganci — Sat, 03 Mar 2007 10:33:00 GMT

La continuazione del post su una implementazione concreta del model view presenter tramite la tecnica del TDD

Un esempio concreto di sviluppo di una GUI in TDD

Antonio Ganci — Fri, 02 Mar 2007 10:12:00 GMT

Per comprendere meglio i concetti esposti in questo post consiglio prima la visione del seguente webcast, la lettura degli articoli che avevo segnalato nel precente post ed infine consiglio l'ascolto dell'ottimo webcast di Corrado Cavalli scaricabile da guisa.

Per prima cosa vediamo uno screen shot della user interface che vogliamo sviluppare in TDD:

La form precedente serve per selezionare un titolo del mercato azionario (nel dominio utente chiamato symbol), permettendo di scegliere se aggiungerlo ad uno dei chart correntemente visualizzati o crearne uno nuovo. In una finestra si possono visualizzare più chart ognuno contenente uno o più titoli.

A questo punto entrano in gioco tre attori: il model, il presenter e la view. Iniziamo vedendo lo schema delle dipendenze tra le tre classi:

Il presenter contiene un riferimento al model e alla view, mentre il model e la view comunicano con il presenter tramite eventi.

La view è la nostra form ed in generale la user interface, il model usa gli oggetti di business o di dominio e non sa nulla di user interface, mentre il presenter è la colla tra i due mondi cioè trasforma le informazioni degli oggetti di dominio in una forma visualizzabile facilmente dalla user interface.

Iniziamo a sviluppare in TDD il presenter; per poterlo testare agevolmente facciamo in modo che dipendenda da due interfacce una che verrà implementata dal model e l'altra dalla view.

Per non scrivermi a mano degli stub userò il framework Rhino Mocks (maggiori informazioni nel post di papo e nel mio precedente).

Il primo test che scriveremo riguarda il riempimento della combobox con i nomi dei symboli. Questa informazione verrà fornita dal model tramite un evento, vediamo il sequence diagram:

In pratica quando nel model viene chiamato il metodo SetSymbolNameList viene segnalato l'evento SymbolNameListChanged a cui il presenter è sottoscritto; e nell'event handler viene chiamata la vista in modo che venga riempita la combobox.

Iniziamo ad impostare la classe di test SelectSymbolPresenterTests:

using MbUnit.Framework;
using Rhino.Mocks;
using Rhino.Mocks.Interfaces;
 
namespace PresenterFirstExample
{
    [TestFixture]
    public class SelectSymbolPresenterTests
    {
        private MockRepository _mocks;
        private ISelectSymbolModel _model;
        private ISelectSymbolView _view;
 
        [SetUp]
        public void SetUp()
        {
            _mocks = new MockRepository();
            _model = _mocks.CreateMock<ISelectSymbolModel>();
            _view = _mocks.CreateMock<ISelectSymbolView>();
        }    
 
        [TearDown]
        public void TearDown()
        {
            _mocks.VerifyAll();
        }
 
        [Test]
        public void WhenTheModelFiresTheSymbolListChangedThePresenterCallsTheViewToFillTheList()
        {
        }
    }
}

Il framework usato è MbUnit, ma la conversione ad altri framework (NUnit, Microsoft Quality Tools) non è un grosso problema.

Il presenter dipende da due interfacce (ISelectSymbolModel e ISelectSymbolView) quindi nel momento in cui scriviamo il test non esiste ancora la form e potrebbe anche non esistere ancora il business layer.

Questo porta dei grossi vantaggi perchè progettando il sistema come se questi due attori non esistessero rende semplice la loro modifica o sostituzione, es: se anzichè una form la view dovesse cambiare in una pagina web l'unica cosa da cambiare è l'implementazione concreta dell'interfaccia ISelectSymbolView, stesso discorso se anzichè una combobox dovessimo usare un DataGrid.

Il nome del test è un pò lungo ma è importante dargli un nome che indichi chiaramente cosa vogliamo testare piuttosto che quello che fa il test. Mi spiego meglio: se il test che abbiamo scritto fallisce leggendo il nome del test si deve essere in grado di capire senza guardare il codice al suo interno cosa del nostro sistema non funziona più correttamente.

La prima cosa che vogliamo testare è che il presenter si sottoscriva all'evento del model, per ottenere questo risultato aggiungiamo al metodo SetUp il seguente codice:

    _model.SymbolNameListChanged += null;
    _symbolNameListChangedRaiser = LastCall.Repeat.Once().IgnoreArguments().GetEventRaiser();

Le due righe di codice precedenti possono sembrare un pò strane, ma è il modo con cui si controlla con rhino mocks se ci si è sottoscritti ad un evento; la variabile _symbolNameListChangedRaiser è di tipo IEventRaiser e verrà usata nel metodo di test per simulare l'evento.

Per far compilare il codice precedente creiamo il model:

using System;
 
namespace PresenterFirstExample
{
    public interface ISelectSymbolModel
    {
        event EventHandler<StringListEventArgs> SymbolNameListChanged;
    }
}

La classe StringListEventArgs:

using System;
 
namespace PresenterFirstExample
{
    public class StringListEventArgs : EventArgs
    {
        private readonly string[] _strings;
 
        public StringListEventArgs(string[] _strings)
        {
            this._strings = _strings;
        }
 
        public string[] StringList { get { return _strings; } }
    }
}

A questo punto finalmente scriviamo il nostro test:

        [Test]
        public void WhenTheModelFiresTheSymbolListChangedThePresenterCallsTheViewToFillTheList()
        {
            string[] symbolNames = new string[] {"ENEL-MIL", "ENI-MIL", "G-MIL"};
 
            _view.FillSymbolNameList(symbolNames);
            LastCall.Repeat.Once();
            _mocks.ReplayAll();
 
            new SelectSymbolPresenter(_model, _view);
            _symbolNameListChangedRaiser.Raise(_model, new StringListEventArgs(symbolNames));
        }

Per chi non è abituato ad usare Rhino Mocks può sembrare un pò ostico, ma è più semplice di quello che sembra. La prima riga crea la variabile symbolNames che contiene l'elenco dei symbol che arriveranno come dati dall'evento (vedi l'ultima riga del test), le due righe successive significano che ci aspettiamo che il presenter chiami la vista passando come argomento l'elenco dei nomi creato prima. La chiamata ReplayAll indica a Rhino Mocks che da quel punto in avanti si è in Play Mode cioè che abbiamo finito il codice in cui dichiaramo che cosa ci aspettiamo che venga chiamato dei nostri oggetti mock.

Se lanciamo adesso il test vediamo che non passa per il seguente motivo:

TestCase 'SelectSymbolPresenterTests.SetUp.WhenTheModelFiresTheSymbolListChangedThePresenterCallsTheViewToFillTheList.TearDown' failed: ISelectSymbolModel.add_SymbolNameListChanged(any); Expected #1, Actual #0.

Per far passare il test scriviamo la classe presenter come segue:

using System;
 
namespace PresenterFirstExample
{
    public class SelectSymbolPresenter
    {
        private readonly ISelectSymbolModel _model;
        private readonly ISelectSymbolView _view;
 
        public SelectSymbolPresenter(ISelectSymbolModel model, ISelectSymbolView view)
        {
            _model = model;
            _view = view;
            _model.SymbolNameListChanged += new EventHandler<StringListEventArgs>(Model_SymbolNameListChanged);
        }
 
        void Model_SymbolNameListChanged(object sender, StringListEventArgs e)
        {
            _view.FillSymbolNameList(e.StringList);
        }
    }
}

A questo punto possiamo iniare a scrivere altre funzionalità.

Continua...

Usare Rhino Mocks per sviluppare in TDD

Antonio Ganci — Wed, 03 Jan 2007 16:47:00 GMT

Per chi sviluppa in TDD utilizzare i Mock Objects è una delle basi dell'interaction based testing.

Per facilitare questo compito sono disponibili alcune librerie in rete. Fino all'anno scorso ho utilizzato TypeMock, ora con l'anno nuovo ho voluto provare un'altra libreria ed ho scaricato Rhino Mocks.

Le prime impressioni sono positive in quanto l'object model mi sembra più chiaro rispetto a TypeMock. Ho avuto qualche difficoltà con in metodi che non ritornano valori (void).

Vediamo un esempio pratico:

Supponiamo di voler creare un mock object della seguente interfaccia:

    public interface ICustomerList
    {
        void Add(Customer customer);
        int Count { get;}
    }

Il codice del test sarà:

    [Test]
    public void RhinoMocksSampleTest()
    {
          MockRepository mockRepository = new MockRepository();
          ICustomerList customers = mockRepository.CreateMock<ICustomerList>();
 
          Expect.Call(customers.Count).Return(10);
          mockRepository.ReplayAll();
 
          Assert.AreEqual(10, customers.Count);
 
          mockRepository.VerifyAll();
    }

Con la chiamata Expect.Call indichiamo che la prossima volta che viene letto il valore della property Count dell'interfaccia ICustomerList viene ritornato il valore 10. Un pò più complicato è invece il mock del metodo Add perchè non ritorna nessun valore e quindi non si può usare ExpectCall:

        [Test]
        public void RhinoMocksSampleTest()
        {
            MockRepository mockRepository = new MockRepository();
            ICustomerList customers = mockRepository.CreateMock<ICustomerList>();
 
            customers.Add(new Customer());
            LastCall.Repeat.Once().IgnoreArguments();
            mockRepository.ReplayAll();
 
            customers.Add(new Customer());
 
            mockRepository.VerifyAll();
        }

In questo caso abbiamo detto che ci aspettiamo una sola chiamata del metodo Add e non ci interessa il valore dei parametri.

Behaviour-Driven Development

Antonio Ganci — Mon, 18 Dec 2006 08:58:00 GMT

Segnalo l'articolo Introducing Behaviour-Driven Development (BDD) di Dan North.

Per me che pratico TDD da alcuni anni è stato illuminante perchè il BDD guida la scrittura dei test dal punto di vista del comportamento del sistema.

Secondo l'articolo è importante rimanere focalizzati sulla domanda:

What’s the next most important thing the system doesn’t do?

Voglio provare ad introdurre le pratiche suggerite nel mio prossimo progetto e verificarne i benefici.

Flexibility vs Efficiency

Antonio Ganci — Mon, 20 Nov 2006 12:04:00 GMT

Segnalo il post Flexibility vs Efficiency.

Fonte: joel reddit

Nell'articolo viene paragonato l'approccio agile a quello waterfall, sostenendo che il metodo waterfall è più efficiente nel caso in cui non ci siano cambiamenti durante la realizzazione di un progetto, mentre il secondo reagisce velocemente alle modifiche (praticamente tutti i progetti software).

Il Test di Joel per un team agile

Antonio Ganci — Wed, 11 Oct 2006 09:22:00 GMT

Joel Spolsky ha creato un semplice test di dodici domande per valutare la qualità di un gruppo di sviluppo software. Le risposte consentite sono si o no dopodicè si fa la somma dei si:

Usate un sistema per il versionamento del codice?
Potete compilare una build in un solo passo?
Fate compilazioni giornaliere?
Avete un database dei bug?
Sistemate i bug prima di scrivere nuovo codice?
Avete una tabella di marcia aggiornata?
Avete delle specifiche?
I programmatori lavorano in un posto tranquillo?
Usate i migliori strumenti sul mercato?
Avete dei tester?
I candidati scrivono codice durante il colloquio?
Fate test dell'usabilità "da corridoio"?

L'idea mi piace e vorrei proporre una lista di domande per calcolare quando agile è un gruppo di sviluppo software:

Fate tutti i giorni lo standup meeting?
Il vostro codice è coperto da test automatici?
Quando viene segnalato un nuovo bug scrivete un test automatico che lo riproduca?
Avete una build automatica notturna, la quale fallisce se tutti i test automatici non passano?
Lavorate con iterazioni non più lunghe di 15 giorni?
Organizzate Design Review almeno una volta al mese?
Organizzate planning game dopo ogni iterazione in cui partecipa anche il cliente?
Fate pair programming per almeno un quarto del tempo di sviluppo?
Raccogliete e pubblicate metriche sul software e sulle attività svolte?
I requisiti sono raccolti come User Story della durata non superiore ad una iterazione?
Stimate le attività prima di svolgerle?
Almeno due volte all'anno fate un meeting in cui si valutano la qualità delle pratiche usate?

Una risposta affermativa ad una domanda si può dare solo se tutto il team attua quell'attività, basta che un solo membro non la segua affinchè la risposta sia no. Ad ogni si, si ottiene un punto, se il punteggio complessivo non è almeno 10 il team non può considerarsi agile.

Cosa ne pensate? L'ho scritto di getto quindi potrei aver dimenticato qualcosa di importante.