Dois-je dupliquer des tests pour des surcharges de commodité?

Question

Il m'est très courant de faire des surcharges pratiques pour les méthodes. Voici un exemple de quelque chose que je pourrais faire:

public void Encode(string value) { 
    Encode(value, DefaultEncoding); 
} 

public void Encode(string value, Encoding encoding) { 
    // ... 
} 

Je commence à accorder plus d'attention aux tests unitaires et les méthodes d'essai comme celui-ci présente quelques obstacles que je ne suis pas sûr que je me fais confiance à seule approche. Le premier et le plus important problème est de savoir si je devrais dupliquer les tests pour les deux surcharges. Par exemple, les deux méthodes doivent lancer ArgumentNullException si la valeur est null; Est-il plus correct de reconnaître être être une logique différente et d'écrire deux tests ou est-il préférable de supposer que les surcharges de commodité n'ont pas de logique propre?

J'ai aussi un problème secondaire. Mon schéma de nommage est le même que celui de Roy Osherove: "MemberName_State_ExpectedResult". Si je duplique des tests, alors j'ai des noms contradictoires sans introduire une convention de nommage bizarre. Comment gérez-vous cela si vous dupliquez des tests?

Answer 1

Je ne vérifie pas souvent les méthodes de commodité au même niveau de détail que la méthode de base qu'elles appellent. Par exemple votre cas ArgumentNullException. Je ne le testerais pas deux fois. Mon sentiment est que les tests unitaires sont des tests en boîte blanche. Je suis autorisé à connaître la mise en œuvre.

Bien sûr, cela pourrait signifier que je vais être brûlé quand je vais et refactoriser plus tard et ajouter des fonctionnalités à la méthode pratique. Mais je suis assez décent de faire TDD (pas un zélote complet comme vous pouvez le dire à partir du premier paragraphe). Donc, je pense que je écrirais probablement un test pour cette nouvelle fonctionnalité et le couvrir alors.

Je ne prétends pas que c'est plus ou moins correct. C'est juste ce que je fais.

Answer 2

Si tous vos constructeurs appellent le constructeur entièrement spécifié, je briserai les essais en
1) votre test unitaire en cours, qui doit être quelque chose comme
ConstructorShouldDoThisAndThat()
2) des tests unitaires spécialisés pour les surcharges , en précisant ce que par défaut les utilisations de surcharge, comme ConstructorWithNoEncodingShouldSetEncodingToDefaultEncoding()

Answer 3

« écrire deux essais ou est-il préférable de supposer que les surcharges de proximité ont pas leur propre logique? »

Umm .... Vos tests ne sont pas définis par "hypothèses". Ils sont définis par la conception de la classe que vous testez.

Vous ne faites rien sur la base de "hypothèses".

Si la fonction de commodité est en fait une fonction de commodité, il doit faire la même chose et vous devez écrire un test qui montre que les deux méthodes variante fait font la même chose.

Si « il pourrait être logique différente » (1), il est pas vraiment une fonction de commodité et (2) vous doit écrire un test qui montre que les deux méthodes variante fait faire la bonne chose (qui peut être le même avec une logique différente, ou peut être différent, je ne peux pas dire à partir de la question.)

"MemberName_State_ExpectedResult. Si dupliquer les tests, alors j'ai des noms affrontant"

Évitez les questions stupides de cohérence. Si vous avez la même méthode avec des signatures différentes, alors cette convention de nommage n'est pas très bonne, n'est-ce pas? S'en tenir fidèlement, malgré ses problèmes, est une consistance stupide.

Vous ne pouvez pas l'utiliser de manière triviale lorsque vous avez des méthodes qui ne sont distinguées que par des signatures d'argument. Donc, faites juste quelque chose qui fonctionne pour toutes vos fonctions de confort.

Answer 4

Je pense que la réponse est plus simple alors vous pensez: vous soucier si les méthodes surchargées fonctionnent ou non? Si vous tenez à ce qu'ils fonctionnent, comment savez-vous avec certitude, sauf si vous les tester?

Cela devrait vous prendre environ 15 secondes pour écrire un test qui compare la sortie de la fonction surchargée avec celle qui est surchargée. Fais-le et continue.

Answer 5

Ce que je fais habituellement est de faire la «vraie» méthode virtuelle. Cela signifie que je peux tester la méthode de commodité en utilisant une classe dérivée spécifique au test (généralement créée par un simulacre dynamique) pour vérifier qu'elle appelle correctement la méthode «réelle». Si la seule différence entre la méthode "réelle" et la méthode pratique est l'utilisation d'une valeur par défaut pour un paramètre particulier, vous pouvez couvrir ceci avec un test unitaire et passer à autre chose.

Deuxième réponse de S.Lott concernant la convention de nommage.