Creazione di una funzione di mappatura Attraverso TDD: troppo tempo trascorso test di scrittura?

Question

Sono un grande appassionato di TDD, e sempre si sforzano di scrivere i test prima di scrivere codice di produzione per garantire il corretto comportamento del codice che sto scrivendo. Di tanto in tanto, però, molti domanda se è prudente scrivere un grande corpo di prove per alcuni tipi di metodi. Questo sembra venire più spesso quando si scrive una classe mapper.

public class FooBarMapper
{
    public Foo MapToFoo(Bar bar)
    {
        return new Foo
        {
            Id = bar.Id,
            Name = bar.Name,
            FooYuk = bar.Beverage,
            /* ... */
        };
    }
}

Dire per esempio che ci sono circa una dozzina di oggetti da mappare sopra. In un ambiente TDD, prima di scrivere qualsiasi delle mappature, probabilmente sarei scrivere un test. Qualcosa di simile MapToFooMapsBeverageToFooYuk(). Il test ha esito negativo, portandomi a scrivere il codice per farlo passare. Ripeto questo per ogni proprietà per mappare. La domanda è: È questo l'assunzione di test-primo sviluppo troppo lontano? Personalmente non la penso così, come io preferirei avere una suite completa di test che mi dicono esattamente ciò che fa il codice, ma mi piacerebbe sentire il tuo parere.

Answer 1

Anche lo zio Bob Martin, uno strenuo difensore della TDD e tutte le cose TDD, dice che non c'è bisogno di scrivere unit test per ogni proprietà banale (una proprietà banale essere definita come una proprietà che ottiene solo e imposta una variabile membro ).

Se avete mai scritto una proprietà che ha effetti collaterali (che dubito si vuole), poi è possibile aggiungere uno unit test ad esso. Come DuffyMo fa notare, se le proprietà sono coperti da test funzionali, non ci dovrebbe essere bisogno di test di unità, dal momento che non v'è alcuna specifiche di funzionalità si sta definendo con il test di unità, diverso dal get banale / set.

Answer 2

Forse questo è ciò che FitNesse è nata per.

Answer 3

In questo caso, mi piacerebbe scrivere un singolo test che mette alla prova tutte le proprietà banali in una sola volta. E non del tutto è il modo standard di fare le cose, ma alla fine, i test per singole proprietà banali sarebbe probabilmente riscritta in un unico banco di prova per tutte le proprietà. Dal momento che le proprietà sono banali, propongo partendo con il test avresti finito con.

Answer 4

Dopo la mappatura dei primi tre proprietà, vorrei vedere la duplicazione e sostituirlo con l'iterazione sulle proprietà e ad assegnare loro utilizzando la riflessione. Che necessita solo di poche prove: 0 immobili, 1 struttura, 5 proprietà, oggetto di destinazione non ha le proprietà attese, oggetto di origine non ha le proprietà attese. Ora posso riutilizzare questo motore generale mappatura ovunque in tutte le mie applicazioni e non dover controllare ogni volta che lo uso.