Sviluppo "guidato": il Test Driven Development

Il test driven development (TDD) è una pratica agile che richiede la creazione di test prima della scrittura del codice sorgente stesso da testare. In realtà è una metodologia utilizzata non per testare il codice, bensì per individuare con precisione le specifiche del software stesso. Ma come avviene questa tipologia di sviluppo? Come mostrato nella figura 1 la prima cosa da fare è quella di creare un test. Il secondo passo consiste nell'eseguire il test. Ovviamente non essendo ancora stato scritto codice per quel test, l'esecuzione del test comporta un fallimento. Occorre quindi apportare delle modifiche al codice in modo che il test sia superato e una volta che ciò avviene si continua con lo sviluppo.

Figura 1. Diagramma sviluppo TDD

Vediamo ora un esempio semplice di codice:

-          Aggiungiamo il test

public void NumberToEnglishShouldReturnOne()

{

  string actual = English.NumberToEnglish(1);

  Assert.AreEqual("one", actual, "Expected the result to be \"one\"");

}

-          Eseguiamo il test. Il test fallisce in quanto il codice non è stato ancora implementato

"NumbersInWords.Test.EnglishTest.NumberToEnglishShouldReturnOne :

    System.Exception :

The method or operation is not implemented.".

-         Scriviamo il codice in modo che il test sia superato

public static string NumberToEnglish(int number)

{

  return "one";

}

-          Eseguiamo di nuovo il test

-          Una volta che il test è passato il prossimo passo è iniziare di nuovo il processo (code refactoring)

Ad esempio il nuovo test sarà:

public void NumberToEnglishShouldReturnTwo()

{

  string actual = English.NumberToEnglish(2);

  Assert.AreEqual("two", actual, "Expected the result to be \"two\"");

}

Quindi modifichiamo il codice in modo che il test sia passato:

public static string NumberToEnglish(int number)

{

  if (number == 1)

    return "one";

  else

    return "two";

}

Ma quali sono i vantaggi di questa metodologia? Il codice. può essere testato singolarmente, sono individuate con precisione le specifiche del codice e sicuramente permette di individuare con facilità lo stato di avanzamento del progetto. Per ulteriori informazioni sul TDD date un'occhiata a questa pagina.

Interview question: Repository Pattern e Factory Pattern

Oggi parleremo di Repository Pattern e Factory Pattern. Entrambi fanno parte della categoria dei Design pattern ossia quell'insieme di schemi di progettazione che permettono di risolvere problemi riccorrenti. Esistono diversi tipi di pattern che sono classificati in base a diversi criteri. Solitamente si sceglie di classificare i pattern a seconda del problema che trattano.
In questo post tratteremo due pattern in particolare: il Factory Pattern e il Repository Pattern. Il Factory Pattern rientra nella categoria dei "pattern creazionali" ossia tutti quei pattern che si nascondono i costruttori delle classi "camuffandoli" con metodi in modo che si possano utilizzare gli oggetti senza sapere come siano utilizzati (un po' come fanno le interfacce). Questo pattern aiuta a modellare un interfaccia per la creazione di un oggetto il quale nel momento in cui viene creato può permettere alle sue sottoclassi di decidere quale classe instanziare.

Questo pattern, come mostrato in figura, è usato quando la classe Creato non conosce in anticipo tutte le sue sottoclassi che andrà a creare. Invce è lasciata ad ogni sottoclasse, la ConcreteCreator, la responsabilità della creazione dell'istanza dell'oggetto corrente.

Il Repository Pattern fa parte dell'insieme dei pattern architetturali che non operano a livello di design e quindi non sono considerati veri e propri pattern. Questo pattern vuole evitare l'accesso diretto alle fonti dati come database, servizi web, liste sharepoint ecc. in quanto questo comperterebbe diversi problemi come codice duplicato, alto rischio di errori di programmazione, tipizzazione debole dei dati di business e cosi via. Cosa propone questo pattern? L'utilizzo di un repository per separare la logica di ritrovamento dei dati dalla logica di bussiness.

In questo modo la logica di bussiness e il data source non comunicano direttamente ma lo fanno solo attraverso i repository come mostrato in precedenza nella figura.