Puis-je le faire dans mes tests unitaires?

Question

Je ne suis pas sûr de ce que je devrais faire ici. Devrais-je coder en dur toutes les valeurs ou devrais-je les avoir dans une variable CONST? Tout ce que j'ai vu semble coder dur les valeurs, donc je ne suis pas sûr.

Comme c'est ce que je faisais maintenant. Dites dans mon contrôleur que j'ai eu un test de validation pour vérifier si l'utilisateur essaie de soumettre un formulaire avec un champ vide.

Maintenant, je voudrais avoir une instruction if vérifiant la variable vide ou nulle. Si cela se produisait alors j'ajouterais l'erreur à ModelState avec un message d'erreur que j'ai écrit.

Ainsi, dans mon test unitaire, je veux m'assurer que si une variable de formulaire vierge est soumise, elle sera interceptée.

maintenant dans mes tests unitaires que je viens de faire une varible CONST et copié et collé le message de validation.

Donc, dans mon assert je compare ce que le message réel est comparé au message stocké dans mon CONST Varrible. Je fais ceci en appelant comme l'état du modèle et appelez le champ là où je m'attends à ce que l'erreur soit. .

Comme:

de result.ViewData.ModelState [ "nom d'utilisateur"] Erreurs [0];

Donc, si le message est là alors il doit avoir entré dans mon code sinon il n'existerait pas.

Il m'est apparu que je devrais peut-être créer une nouvelle classe qui serait statique et contenir toutes ces variables CONST.

De cette façon, les vues du contrôleur et les tests unitaires peuvent les utiliser. De cette façon, si je dois changer le message d'erreur, je n'ai qu'à le changer à un endroit. Comme je ne suis pas en train de tester le message d'erreur que je suis en train de tester s'il est défini. La même chose à dire pour les exceptions J'ai quelques messages personnalisés mais je ne suis pas en train de tester si le message est correct, plus si l'attente est attrapée.

La façon dont je le teste cependant est de voir si le message est le message que je m'attends puisque si ce n'est pas le message ou le message n'existe pas alors quelque chose s'est mal passé. Je suis novice dans les tests unitaires, donc je voulais m'assurer que ce que je ferais ne dérangerait pas mes tests unitaires.

Pour moi, cela a du sens, mais je pensais mieux vérifier d'abord.

Merci

Answer 1

Il est important d'écrire chaque test d'une manière qui soit robuste aux changements ultérieurs. Vous aurez souvent besoin de changer des parties de votre application à une date ultérieure, et chaque fois que vous faites cela, il y a un risque que vous cassiez un de vos tests.

Si vos tests sont robustes à changer, un test défaillant indiquera vraiment un bug de régression. Cependant, si vos tests s'appellent Overspecified Tests, chaque petite modification apportée à votre base de code peut entraîner l'échec des tests, non pas parce qu'il y avait un bug de régression, mais parce que le test est trop fragile. Quand cela arrive, vous perdez la foi dans vos tests; la maintenance de test prend beaucoup de temps, et vous finirez par abandonner complètement la suite de tests. En lisant votre question, vous commencez déjà à voir les contours de cet anti-pattern. Je suppose que c'est pourquoi vous ne testez pas pour les textes spécifiques retournés, mais simplement s'ils sont en train d'être mis en place. Je pense que c'est correct - je teste rarement des chaînes spécifiques, mais plutôt si une chaîne est spécifiée du tout. Cela rend le test plus robuste à changer, et vous évitez l'anti-modèle de test Overspecified.

Dans de nombreux cas, au lieu de faire un Assert.AreEqual sur deux chaînes, vous pouvez simplement utiliser Assert.IsNotNull, ou peut-être Assert.IsFalse(string.IsNullOrEmpty(result)) (votre plate-forme semble être .NET).

En général, les affirmations fondées sur les valeurs dérivées sont très robustes pour changer, donc vous pouvez jeter un coup d'oeil au blog suivant:

• Derived Values Ensure Executable Specification

Si vous vous sentez particulièrement aventureux , Je ne peux que vous recommander de lire xUnit Test Patterns, d'où proviennent de nombreux motifs et anti-motifs que je mentionne. The Art of Unit Testing est également bon ...

Answer 2

« Au cas où je hardcoding toutes les valeurs ou devrais-je les avoir dans une variable Const. »

Je ne suis pas sûr de ce que vous voulez dire. Il est bon d'avoir des variables const dans la classe de test unitaire. .: par exemple

class FooTest 
{ 
    private static readonly string FOO_MESSAGE = "BAR"; 

ou

public static const string BAZ_MESSAGE = "BOO"; 

... 

    Assert.AreEqual(FOO_MESSAGE, e.ToString()); 
} 

« Il me vint peut-être que je devrais faire une nouvelle classe qui sera statique et tenir toutes ces variables CONST.

De cette façon, les vues du contrôleur et les tests unitaires peuvent les utiliser. De cette façon, si je dois changer le message d'erreur, je n'ai qu'à le changer à un endroit. "

Cela semble faux Le mécanisme utilisé par le contrôleur pour émettre des erreurs lui est privé. En agissant ainsi, vous augmentez la probabilité que les erreurs ne se produisent pas, le contrôleur et les tests seront "d'accord" du fait qu'ils utilisent le même mécanisme semi-public

"Puisque je ne suis pas en train de tester le message d'erreur, je suis en train de tester s'il est configuré."

Si vous ne testez pas vraiment le message, pourquoi le test devrait-il le connaître?