Typage implicite et TDD

Question

Je viens de lire ceci post et il fait la preuve contre le typage implicite en utilisant lors du démarrage avec Test piloté par développement/conception. Son message dit que TDD peut être "ralenti" lors de l'utilisation de la typage implicite pour le type de retour lors de l'unité de test d'une méthode. En outre, il semble vouloir le type de retour spécifié par le test afin de conduire le développement (ce qui est logique pour moi).

Un test unitaire donné avec le typage implicite pourrait ressembler à ceci:

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

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

Mes questions sont les suivantes:

Le fait d'utiliser l'aide de frappe implicite ou entraver les tests unitaires d'écriture pour TDD? Y at-il quelqu'un là-bas qui peut partager son expérience en utilisant cette technique lors de l'écriture des tests unitaires?

Je demande cela parce que bientôt je n'ai pas fait TDD et je veux savoir s'il existe un moyen d'écrire des tests unitaires génériques ou semi-génériques qui fonctionneraient un type de retour pourrait changer.

Answer 1

Je vois son point mais je ne pense pas vraiment que ce soit la bonne raison de ne pas utiliser var ici. Rappelez-vous, TDD fonctionne à peu près comme suit:

1. Rédiger un nouveau test.
2. Si le test échoue (et il devrait échouer!), Écrivez suffisamment de code jusqu'à ce que le test compile.
3. Exécuter tous les tests.
4. Si un test échoue, écrivez suffisamment de code jusqu'à ce que tous les tests aient réussi.
5. Refactor.

Que nous utilisions ou non le var, le test échouerait à compiler de toute façon car la méthode testée n'existerait pas encore! Une fois que nous commençons à coder NewMethod ses points sont plutôt discutables.

La bonne raison de ne pas utiliser var est que le code ne donne aucune indication du type de result. Ceci est une question d'opinion, mais var est bien ici

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

et pour les types anonymes, mais pas ici

var m = M(); 

parce qu'il est tout à fait clair sans aller à la déclaration de M (ou en utilisant IntelliSense) ce que le le type de retour de M est.

Answer 2

Oui et Non

Dans Visual Studio actuellement, TDD est un peu d'une douleur, en particulier lors de l'utilisation typage implicitement. var signifie pas d'intellisense, alors quand vous entrez le nom d'un type qui n'existe peut-être pas encore, il a tendance à s'auto-compléter avec quelque chose qui est similaire à ce que vous tapez, souvent le nom du test.

Visual Studio 2010 a un consume first mode, ce qui le rend idéal et meilleur pour le développement piloté par les tests.Actuellement, vous trouverez (en 2008 et plus tôt) vous devez frapper échapper pour cacher intellisense. En ce qui concerne l'utilisation de var, il s'agit de sucre purement syn- matique. Il fait ce qui suit beaucoup plus agréable à mon avis:

var type = new MyType(); 

Son clair que le type de variable, est de type MyType. var est génial pour les génériques et suit le principe de DRY - Ne vous répétez pas. D'autre part, cela rend le code difficile à lire, que vous suiviez ou pas TDD. Les bons tests unitaires doivent être fluides et faciles à lire. Si vous devez penser, ou passer la souris sur une méthode pour voir le type de retour, c'est le signe d'un mauvais test, difficile à lire.

Answer 3

Du point de vue de l'outillage, je dirais que c'est plus agréable d'éviter le var. J'utilise Eclipse et Java, mais je sais que les extensions telles que CodeRush et Resharper offrent de nombreuses fonctionnalités dont je parle ici. Quand dans mon test j'appelle une méthode qui n'existe pas encore, je peux la "réparer rapidement" pour créer la méthode dans la classe désirée. Le type de retour de la méthode créée automatiquement dépend de son contexte; si j'attends une chaîne, le type de retour de la méthode sera String. Mais si l'affectation est à un var (ce que Java n'a pas - mais si c'est le cas), l'EDI n'en connait pas assez pour rendre le type de retour autre que var (ou peut-être Object).

Tout le monde n'utilise pas l'IDE de cette manière dans TDD, mais je le trouve très utile. Plus je peux donner d'informations à l'IDE dans mon test, moins je dois taper pour faire passer le test.