Digitazione implicita e TDD

Question

Ho appena letto questo post e questo è il caso contro la digitazione implicita che si utilizza quando si inizia con lo sviluppo/progettazione Test driven.

Il suo post dice che il TDD può essere "rallentato" quando si utilizza la digitazione implicita per il tipo restituito quando l'unità testa un metodo. Inoltre, sembra che voglia il tipo di ritorno specificato dal test per guidare lo sviluppo (che per me ha senso).

Un dato prova di unità con la tipizzazione implicita potrebbe assomigliare a questo:

public void Test_SomeMethod() 
{ 
    MyClass myClass = new MyClass(); 

    var result = myClass.MethodUnderTest(); 
    Assert.AreEqual(someCondition, result); 
} 

Quindi le mie domande sono:

funziona utilizzando aiuto tipizzazione implicita o ostacolare test di unità di scrittura per TDD? C'è qualcuno là fuori che può condividere la propria esperienza usando questa tecnica durante la scrittura dei test unitari?

Chiedo questo perché presto non ho fatto TDD e voglio sapere se c'è un modo per scrivere test unitari generici o semi-generici che funzionerebbero un tipo di ritorno potrebbe cambiare.

Answer 1

Vedo il suo punto ma non penso davvero che sia il motivo giusto per non utilizzare var qui. Ricorda, TDD funziona approssimativamente in base al seguente:

1. Scrivere un nuovo test.
2. Se il test non riesce a compilare (e dovrebbe fallire!), Scrivere codice sufficiente fino alla compilazione del test.
3. Eseguire tutti i test.
4. Se un test fallisce, scrivere codice sufficiente fino al termine di tutti i test.
5. Refactor.

O se non usiamo var il test avrà esito negativo per la compilazione in entrambi i casi perché il metodo in prova non esisterà ancora !. Una volta che iniziamo a programmare NewMethod i suoi punti sono piuttosto discutibili.

Piuttosto, il motivo giusto per non utilizzare var qui è perché il codice non dà alcuna indicazione sul tipo di result. Si tratta di una questione di opinione, ma var va bene qui

var dict = new Dictionary<Foo, List<Bar>>(); 

e per i tipi anonimi, ma non qui

var m = M(); 

perché è del tutto chiaro, senza andare alla dichiarazione di M (o utilizzando IntelliSense) ciò che il tipo di ritorno di M è.

Answer 2

Sì e No

In Visual Studio attualmente, TDD è un po 'di dolore, soprattutto quando si utilizza la digitazione implicitamente. var significa nessuna intellisense, poi quando si inserire il nome di un tipo che non può esistere eppure ha la tendenza per il completamento automatico con qualcosa che è simile a quello che si sta digitando, spesso il nome del dispositivo di prova.

Visual Studio 2010 ha uno consume first mode, che lo rende ideale e migliore per Test Driven Development.Attualmente troverai (nel 2008 e in precedenza) devi colpire escape per nascondere intellisense.

Come per l'uso di var è zucchero puramente sintetico. Rende la seguente molto più bello a mio parere:

var type = new MyType(); 

suo chiaro che il tipo di variabile, è di tipo MyType. var è ottimo per i generici e segue il principio di DRY - Non ripetersi.

var type = MethodCall(); 

var result = ReturnResult(); 

D'altra parte, questo rende difficile per leggere il codice, se si segue TDD o no. Buoni test unitari dovrebbero fluire ed essere facili da leggere. Se devi pensare o passare il mouse su un metodo per vedere il tipo restituito, questo è il segno di un test non valido e difficile da leggere.

Answer 3

Dal punto di vista degli utensili, direi che è meglio evitare il var. Uso Eclipse e Java, ma so che estensioni come CodeRush e Resharper offrono molte delle funzionalità di cui sto discutendo qui. Quando nel mio test chiamo un metodo che non esiste ancora, posso "risolverlo rapidamente" per creare il metodo nella classe desiderata. Il tipo di ritorno del metodo creato automaticamente dipende dal suo contesto; se mi aspetto di restituire una stringa, il tipo restituito del metodo sarà String. Ma se l'assegnazione è a una var (che Java non ha - ma se lo ha fatto), l'IDE non ne sa abbastanza da rendere il tipo di ritorno diverso da var (o forse Object).

Non tutti utilizzano l'IDE in questo modo in TDD, ma lo trovo molto utile. Più informazioni riesco a fornire l'IDE nel mio test, minore è la necessità di digitare per eseguire il test.