Disons que j'ai une classe qui a une méthode pour calculer quelque chose (cela n'a pas vraiment d'importance). Cela pourrait ressembler à quelque chose comme ceci:
var result = example.CalculateDateStuff(DateTime.Now);
3 Réponses :
Ceci est juste mon avis, mais si vous utilisez des tests unitaires, vous devez essayer de tester exactement ce que vous faites normalement avec votre code. En utilisant une entrée différente, mais comme vous l'utilisez.
Le premier exemple, semble être un cas que vous utilisez dans votre code: vous créez une classe, remplissez-la et appelez la méthode.
La seconde, à mon avis, semble surcharger toute la situation, car ce n'est pas comme le cas réel, et vous devez également ajouter du code pour chaque situation spécifique.
Imaginez un cas dans lequel vous avez 10 biens et 10 méthodes: combien cette classe peut pousser?
Vous ne devez pas ajouter de méthodes supplémentaires, juste pour tester d'autres méthodes. Ce que vous faites est correct. En règle générale, un test unitaire est composé de 3 étapes (la dénomination des étapes peut varier):
Dans votre cas: P>
void UnitTest()
{
//Setup
var example = new Example();
example.InputValue = 42;
//Action
var result = example.CalculateStuff()
//Assert
Assert.AreEqual(84, result);
}
Bon point. Qu'en est-il de l'exemple où la valeur d'entrée est une DateTime avec la valeur datetime.now ?
Vous pouvez définir l'exemple.InputValue = DateTime.Now dans votre intime
Un test clair ne peut être écrit que si vous avez clairement le code.
Votre premier exemple où vous réussissez ce que vous avez besoin sur votre méthode est le moyen le plus simple de le faire.
Pourquoi? Simplement parce que l'entrée fait partie de la méthode sous test. Si votre contribution fait partie de la classe elle-même, vous perdez la clarté. Ce code peut être simple maintenant, mais plus tard, il peut facilement devenir autre chose. Vous avez maintenant des données qui vivent en dehors de votre méthode sous test, ce qui signifie maintenant que vous devez maintenir l'état. Ne faites pas cela.
En termes d'autres types de données telles que DateTime, la réponse est la même, votre valeur DateTime est un paramètre et vous pouvez passer DateTime.Now à votre méthode.
En bout de ligne, étant donné un choix, je tiens à cette construction tout le temps:
Cela signifie-t-il que lorsqu'il est appelé à l'extérieur du test, vous l'appelleriez comme ceci: var résultat = exemple.calculaestuff (exemple.inPutValue) ?
Non, cela signifie que je changerais le code afin que cela ne nécessite pas / utilise une variable de classe interne qui introduit l'état
Le premier semble assez simple, je ne vois aucun avantage à ce dernier. Quel problème avez-vous rencontré avec le premier?
@David que si la valeur d'entrée est un
DateTime et la valeur est toujoursdatetime.now par exemple. De cette façon, vous devriez créer une propriété sur la classe , qui est toujours définie surdatetime.now , qui semble un peu impair.Est-ce tdd? Pourquoi dites-vous "je pourrais aussi faire"? En ce qui concerne la méthode statique ou non, c'est une autre histoire .
Je ne vois aucune différence dans les deux. Vous testez exactement le même algorithme. Mais en général, je testerais des objets et des méthodes telles qu'elles sont utilisées dans le code. Donc, première option imo est la voie à suivre. Surtout, lorsque la méthode dépend des variables privées / état d'un objet.
@ Jakobbusksørensen: Il n'y a pas de
DateTime dans le code indiqué. Et si l'entrée doit toujours êtreDateTime.now alors pourquoi doit-il être fourni? Pourquoi la méthode ne peut-elle pas simplement utiliserdatetime.now ? Ce n'est toujours pas clair pour moi quel problème vous essayez de résoudre.@David je sais. Je cherchais si il y avait ou non un modèle de Dessign (-SH) pour ce type de problème. Donc, le problème est plus générique que l'exemple. S'il n'y a pas de motif et "ça dépend", ça va aussi bien. De cette façon, je sais, c'est juste une question d'opinion :-)