Come scrivere prima il test dell'unità e poi il codice?

Question

Sono nuovo al test delle unità e ho letto più volte che dovremmo scrivere prima il test dell'unità e poi il codice effettivo. A partire da ora, scrivo i miei metodi e poi collaudo il codice.

Se si scrivono i test prima ...

si tende a scrivere il codice per adattare i test. Questo incoraggia la "la cosa più semplice che risolve il problema" tipo di sviluppo e mantiene si è concentrato sulla risoluzione del problema non lavorando su meta-problemi.

Se si scrive il codice prima ...

Sarete tentati di scrivere i test per adattare il codice. In effetti questo è l'equivalente di scrivere il problema per adattarsi alla tua risposta, che è tipo all'indietro e molto spesso porterà a test che sono di valore inferiore .

Mi sembra buono. Tuttavia, come scrivo i test unitari prima ancora di avere il mio codice in posizione? Sto prendendo il consiglio alla lettera? Significa che dovrei avere le mie classi e interfacce POCO sul posto e poi scrivere il test unitario?

Qualcuno può spiegarmi come si fa con un semplice esempio di aggiungere due numeri?

Answer 1

È davvero semplice. Red, Green, Refactor.

Rosso significa che il codice è completamente danneggiato. L'evidenziazione della sintassi mostra il rosso e il test non passa. Perché? Non hai ancora scritto alcun codice.

Verde significa: la build dell'applicazione e i passaggi di test. Hai aggiunto il codice richiesto.

Mezzi di refittamento: pulirlo e assicurarsi che il test passi.

si può iniziare scrivendo un test un po 'come questo:

[TestMethod] 
public void Can_Create_MathClass() { 
    var math = new MathClass(); 
    Assert.IsNotNull(math); 
} 

Questo fallirà (RED). Come lo aggiustate? Crea la classe.

public class MathClass { 
} 

Questo è tutto. Ora passa (GREEN). Prossimo test:

[TestMethod] 
public void Can_Add_Two_Numbers() { 
    var math = new MathClass(); 
    var result = math.Add(1, 2); 
    Assert.AreEqual(3, result); 
} 

Questo fallisce anche (RED). Creare il metodo Add:

public class MathClass { 
    public int Add(int a, int b) { 
     return a + b; 
    } 
} 

eseguire il test. Questo passerà (GREEN).

refactoring è una questione di ripulire il codice. Significa anche che è possibile rimuovere i test ridondanti. Sappiamo che abbiamo il MathClass ora .. in modo da poter rimuovere completamente il test Can_Create_MathClass. Fatto ciò, hai superato il REFATTORE e puoi continuare.

È importante ricordare che la fase di Refactor non si riferisce solo al codice normale. Significa anche test. Non puoi lasciare che i tuoi test si deteriorino nel tempo. Devi includerli nella fase Refactor.

Answer 2

Quando crei i test prima, prima del codice, troverai molto più facile e veloce la creazione del codice. Il tempo combinato necessario per creare un test unitario e creare del codice per farlo passare equivale a codificarlo subito. Ma se hai già i test unitari non hai bisogno di crearli dopo che il codice ti ha salvato un po 'di tempo e molto dopo.

Creazione di un test unitario aiuta uno sviluppatore a prendere veramente in considerazione ciò che deve essere fatto. I requisiti sono saldamente inchiodati dai test. Non ci può essere malinteso una specifica scritta sotto forma di codice eseguibile.

Il codice che verrà creato è semplice e conciso, implementando solo le funzionalità desiderate. Altri sviluppatori possono vedere come utilizzare questo nuovo codice sfogliando i test. Ingresso i cui risultati sono indefiniti sarà assente dalla suite di test

V'è anche un vantaggio per la progettazione del sistema. Spesso è molto difficile testare l'unità di alcuni sistemi software. Questi sistemi sono in genere costruiti prima di codice e sottoposti a test secondari, spesso da un team completamente diverso. Creando test prima il tuo design sarà influenzato dal desiderio di testare tutto ciò che ha valore per i tuoi clienti. Il tuo progetto rifletterà questo essendo più facile da testare.

Answer 3

Facciamo un esempio leggermente più avanzato: vuoi scrivere un metodo che restituisca il numero più grande da una sequenza.

primo luogo, scrivere test di una o più unità per il metodo da testare:

int[] testSeq1 = {1, 4, 8, 120, 34, 56, -1, 3, -13}; 

Assert.That(MaxOf(testSeq1) == 120); 

e ripetere per alcuni più sequenze. Anche un parametro nullo, una sequenza con un elemento e una sequenza vuota e decidere se una sequenza vuota o un parametro nullo dovrebbero un'eccezione (e garantire che il criterio unità prevede un'eccezione per una sequenza vuota se questo è il caso).

È durante questo processo che è necessario decidere il nome del metodo e il tipo dei suoi parametri.

A questo punto, non si compila.

quindi scrivere uno stub per il metodo:

public int MaxOf(IEnumerable<int> sequence) 
{ 
    return 0; 
} 

A questo punto si compila, ma i test di unità sicuro.

Quindi implementare MaxOf() in modo che i test di unità passino ora.

Facendolo in questo modo si garantisce di concentrarsi immediatamente sull'usabilità del metodo, poiché la prima cosa che si tenta di fare è usarla - prima ancora di iniziare a scriverla. Potresti decidere di cambiare leggermente la dichiarazione del metodo a questo punto, in base al modello di utilizzo.

Un esempio del mondo reale applicherebbe questo approccio all'utilizzo di un'intera classe anziché di un solo metodo. Per brevità ho omesso la classe dall'esempio sopra.

Answer 4

È possibile scrivere i test di unità prima di scrivere qualsiasi codice: Visual Studio dispone di funzionalità per generare stub di metodi dal codice che è stato scritto nel test dell'unità. farlo in questo modo può anche aiutare a capire i metodi che l'oggetto dovrà supportare - a volte questo può aiutare miglioramenti successivi (Se hai avuto un salvataggio su disco, anche tu sovraccarichi per salvare in Stream, questo è più testabile e aiuta lo spooling sulla rete, se necessario in seguito)