Dans notre modèle de modèle de domaine principal, nous avons une classe appelée "catégorie" dont le constructeur est interne par conception. Étant donné que le constructeur est interne, lors de la rédaction des cas de test de l'unité, je ne pourrai pas créer l'objet de "catégorie". p>
Donc, ma question, est-ce une meilleure pratique de rendre le constructeur public juste pour rendre la classe "catégorie" testable? Ou je ne devrais pas tester cette "catégorie", je devrais avoir testé la classe / méthode responsable de la création de cet objet? P>
ta, p>
rajeesh p>
4 Réponses :
Ne faites pas le public du constructeur uniquement pour des tests d'unités. Si d'un point de conception, vous avez décidé que cela devrait être interne, laissez-la de cette façon. Testez les classes qui invoquent ce constructeur. P>
in .NET Il y a le InternalsVissibletoTtribute qui vous permet d'exposer les membres internes aux tests unitaires. P>
Ajouter à votre montageInfo.cs. Ensuite, UnittestStassembl.dll code> est capable d'appeler vos méthodes internes. Plus d'infos est disponible ici . p> p>
TDD signifie test- considère pourquoi il est interne. Cela vous indiquera comment résoudre le problème. Vous ne devriez pas rendre le constructeur public juste pour pouvoir le tester, mais vous devriez-vous prendre en compte un design qui facilite la création de nouvelles instances. P> Souvent, les constructeurs sont fabriqués interne pour protéger les invariants, mais vous pouvez aussi bien atteindre le même objectif avec un constructeur public qui prend l'entrée requise en tant que paramètres de constructeur. P> public class MyClass
{
private readonly string requiredString;
public MyClass(string requiredString)
{
if (requiredString == null)
{
throw new ArgumentNullException("requiredString");
}
this.requiredString = requiredString;
}
}
Vous pouvez envisager de créer une méthode d'usine statique nommée
Category *ConstructCategory_ForUnitTest();
J'utilise c #. Le problème que je vois avec "InternalsVissiaTatoTribute" est que nous lions une témoignage au code réel.
Je propose de reformuler le titre reflétant que la question concerne le test unitaire d'une classe avec un constructeur privé / interne.