Unité Test d'une méthode 'SetDefaults()'

Question

Je suis en train d'apprendre le test unitaire. J'ai un «objet de domaine» qui ne fait pas grand-chose en dehors de l'état de blocage (c'est-à-dire «employé» sans logique métier). Il a une méthode SetDefaults() qui remplit juste son état avec des valeurs raisonnables. Une méthode simple. Mais quand je vais au test unitaire, tout ce que je peux penser est de lancer la méthode, puis de vérifier que chaque champ est ce qu'il devrait être. Comme (en C#):

 [TestMethod()] 
    public void SetDefaultsTest() 
    { 
     Employee target = new Employee(); 

     employee.SetDefaults(); 

     Assert.AreEqual(employee.Name, "New Employee"); 
     Assert.AreEqual(employee.Age, 30); 
     // etc. 
    } 

Il se sent mal à reproduire toute la fonctionnalité de SetDefaults() dans mon test. Devrais-je laisser cette méthode non testée? Le problème est que je voudrais un test pour s'assurer que lorsque de nouvelles propriétés sont ajoutées à la classe, elles sont également ajoutées à la méthode SetDefaults().

Answer 1

Les getters et setters triviaux n'ont parfois pas de tests unitaires écrits pour eux. Si c'est tout ce que SetDefaults() fait, ça ne fera probablement pas de mal de l'ignorer.

Une chose que vous voulez envisager des tests, cependant, est qu'aucun des propriétés du jeu de l'instance employee sont nulles après avoir appelé SetDefaults():

var nonNullProperties = new object[] { employee.Name, employee.Age, ... }; 
foreach (var property in nonNullProperties) 
    Assert.IsNotNull(property); 

Cela est logique, puisque vous vraiment juste qu'ils sont mis à une valeur par défaut, et pas tellement qu'ils sont une valeur spécifique.

Answer 2

Cela dépend de la valeur que vous obtenez pour ce test. Ne pas tester juste pour le plaisir de tester. Cependant, si ces valeurs par défaut sont importantes pour être correctes et ne changent pas, alors allez-y. Un grand nombre de tests implique de décider "Hé, est-ce que cela va rendre mon travail plus facile à long terme?" Ces paramètres par défaut changent-ils tout le temps ou sont-ils constants? Les paramètres par défaut sont-ils très compliqués, ou s'agit-il d'une poignée de chaînes et de nombres? Dans quelle mesure est-il important pour le client que ces valeurs par défaut soient correctes? A quel point est-il important pour les autres développeurs que les valeurs par défaut soient correctes?

Le test pourrait faire un million de choses, mais si cela n'ajoute pas de valeur à quelqu'un qui s'en soucie, alors ne vous inquiétez pas. Si vous avez été invité à automatiser les tests de 100% de l'ensemble de votre code, peut-être lire et discuter de certaines des idées présentées dans les blogs suivants pourraient bénéficier de votre équipe:

http://blog.jayfields.com/2009/02/thoughts-on-developer-testing.html http://msdn.microsoft.com/en-us/magazine/cc163665.aspx

Sinon, si ça n'ajoute pas beaucoup de valeur ou ça casse constamment, je dirais aller de l'avant et laisser tomber.

Answer 3

Cela ressemble à un test unitaire assez raisonnable pour moi. Vous fournissez un test simple qui vérifie les résultats de l'appel de cette méthode. Cela ne vous aide pas avec de nouvelles propriétés, car le test existant passerait toujours. Peut-être pourriez-vous utiliser Reflection pour parcourir toutes les propriétés de l'objet et vérifier qu'elles ne sont pas nulles?

Aussi SetDefaults() semble être une méthode un peu étrange. Pourquoi ne pas simplement initialiser un nouveau Employee à ces valeurs pour commencer? De cette façon, il n'y a aucun risque qu'un autre codeur crée un Employee et oublie d'appeler SetDefaults().