tester une classe interne

Question

comment écrire des tests unitaires dans les classes internes ???

Answer 1

Vous écrivez des tests qui spécifient le comportement de l'interface externe de la classe de niveau supérieur. Que cette classe utilise ou non des classes internes pour implémenter ce comportement est un détail d'implémentation de la classe et les tests n'ont pas besoin de savoir quoi que ce soit à son sujet.

Si la classe interne ne peut pas être testée de manière adéquate via l'interface de la classe de niveau supérieur, il est généralement préférable de la sortir de la classe interne et de la tester directement en tant que nouvelle classe de niveau supérieur. Vouloir tester des classes internes est une odeur de code indiquant que la classe interne peut être suffisamment significative pour être une classe de niveau supérieur.

Answer 2

Ce n’est pas ce que je recommanderais, mais vous pouvez également utiliser le InternalsVisibleToAttribute .

Answer 3

Lorsque vous utilisez MS Visual Studio pour les tests unitaires, vous devez simplement créer un private. Accesseur . En interne, cela fonctionne avec des réflexions, je pense. Il suffit de regarder le code généré.

Answer 4

Vous ne le testez pas directement. Il sera testé à travers la classe où il est défini.

Et, si vous appliquez TDD, comme l’impliquent actuellement les étiquettes de question, quel est le test à partir duquel vous écrivez cet appel pour une classe interne? Je veux dire, ne peut-il pas s'agir d'une classe standard appartenant à la classe sur laquelle vous travaillez?

Answer 5

Nous avons utilisé une classe auxiliaire qui utilise la réflexion pour charger et appeler des méthodes sur des classes internes. Il est également possible de changer l’accessibilité au moment de la compilation en utilisant le symbole DEBUG, par exemple

.

#if DEBUG
public
#else
internal
#endif
    class MyInternalClass
{
    ...
}

Cependant, la réponse d’Esko Luontola est plus exacte car c’est la fonctionnalité ou les exigences commerciales qui importent le plus. Il est facile de trop se concentrer sur la couverture de code plutôt que de tester les zones de risque importantes.

Answer 6

Voir les explications détaillées dans http://msdn.microsoft.com/en -us / library / bb385974.aspx