Utiliser la réflexion ou une propriété lors de tests unitaires?

Question

C'est un cours qui m'inquiète un peu. Mon objectif est d'unité d'essai les adresses liste:

public class LabelPrinter 
{ 
    private readonly IEnumerable<Address> _addresses; 

    public LabelPrinter(IEnumerable<Address> addresses) 
    { 
     _addresses = addresses; 
    } 

    public Document Create() 
    { 
     // ... Generate PDF, etc ... 
    } 
} 

Alors, quel est le meilleur:

1. utiliser la réflexion pour inspecter la propriété privée, ou
2. Depuis le IEnumerable d'origine peuvent être modifiés à l'extérieur de toute façon , faire un getter public et le tester à la place?

Answer 1

En particulier lors de l'apprentissage des tests unitaires, les soucis de garder les champs privés sont surpassés par des tests faciles et une meilleure couverture. Option 2.

Answer 2

En règle générale, les membres privés ne doivent pas faire l'objet de tests unitaires, car tout ce que fait la classe avec ses membres privés doit en quelque sorte se refléter dans le comportement testable en externe de l'objet. En d'autres termes, qui se soucie de ce qui se passe là-bas, tant que son comportement extérieur est ce qu'il devrait être. L'unité de test des membres privés couple également vos tests aux internes d'une classe, ce qui les rend plus fragiles. Si vous décidez d'utiliser une collection plus efficace plus tard, vos tests seront interrompus, même si le comportement de l'objet n'a pas changé. Vous voulez surtout éviter la réflexion, puisque la recherche de propriétés par nom signifie que vos tests se cassent si le nom de la propriété change. En d'autres termes - si vous devez tester la classe Address, faites-le à partir de ses propres tests unitaires, plutôt qu'à partir des tests du LabelPrinter. Si vous devez utiliser l'une de vos deux méthodes, utilisez la seconde plutôt que la réflexion.

Answer 3

Qu'essayez-vous de tester sur la liste addresses ici? Dans l'exemple de code que vous avez fourni ci-dessus, votre travail est plutôt facile car vous pouvez injecter la liste via votre constructeur. Donc, dans vos tests, vous pouvez accéder à la liste en tant que telle, et donc pas nécessairement besoin de l'exposer à nouveau:

[Test] 
public void Test() 
{ 
    IEnumerable<Address> addresses = new List<Address>(); 
    LabelPrinter printer = new LabelPrinter(addresses); 

    ... // execute your test here 

    Assert.AreEqual(blah, addresses.get(0)); 
    // or any other assertion you want to make on the addresses list 
    // created up above. 
} 

Answer 4

test Create et non le poseur (ce qui est effectivement ce que vous avez ici). Je trouve que les testeurs/getters testeurs sont une perte de temps. Esp. Comme la plupart du temps, le setter doit être exécuté pour qu'un autre test fonctionne. Ils sont aussi pour la plupart trop simples pour échouer.

Donc plutôt que de valider que LabelPrinter a un _addresses et c'est Y, vérifiez que la sortie de Create inclut les détails pertinents.