Comment tester en unité les méthodes privées ?

Question

Je suis en train de construire une bibliothèque de classes qui aura des méthodes publiques et privées. Je veux être en mesure de tester les méthodes privées (surtout pendant le développement, mais cela pourrait aussi être utile pour une refonte future).

Quelle est la manière correcte de procéder ?

Answer 1

Si vous voulez tester en unité une méthode privée, il y a peut-être un problème. Les tests unitaires sont (généralement) destinés à tester l'interface d'une classe, c'est-à-dire ses méthodes publiques (et protégées). Vous pouvez bien sûr "bidouiller" une solution à ce problème (ne serait-ce qu'en rendant les méthodes publiques), mais vous pouvez aussi y réfléchir :

1. Si la méthode que vous souhaitez tester en vaut vraiment la peine, il peut être intéressant de la déplacer dans sa propre classe.
2. Ajoutez des tests supplémentaires aux méthodes publiques qui appellent la méthode privée, afin de tester la fonctionnalité de cette dernière. (Comme les commentateurs l'ont indiqué, vous ne devriez faire cela que si la fonctionnalité de ces méthodes privées fait réellement partie de l'interface publique. Si elles exécutent en fait des fonctions qui sont cachées à l'utilisateur (c'est-à-dire au test unitaire), c'est probablement mauvais).

Answer 2

Si vous utilisez .net, vous devez utiliser l'option InternalsVisibleToAttribute .

Answer 3

Il n'est pas forcément utile de tester les méthodes privées. Cependant, j'aime aussi parfois appeler des méthodes privées à partir de méthodes de test. La plupart du temps, afin d'éviter la duplication de code pour la génération de données de test...

Microsoft fournit deux mécanismes pour cela :

Accesseurs

• Allez dans le code source de la définition de la classe
• Cliquez avec le bouton droit de la souris sur le nom de la classe
• Choisissez "Créer un accesseur privé".
• Choisissez le projet dans lequel l'accesseur doit être créé. => Vous obtiendrez une nouvelle classe avec le nom foo_accessor. Cette classe sera générée dynamiquement lors de la compilation et fournit tous les membres publics disponibles.

Cependant, le mécanisme est parfois un peu difficile à manier lorsqu'il s'agit de modifier l'interface de la classe d'origine. C'est pourquoi, la plupart du temps, j'évite de l'utiliser.

Classe PrivateObject L'autre moyen est d'utiliser Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject.

// Wrap an already existing instance
PrivateObject accessor = new PrivateObject( objectInstanceToBeWrapped );

// Retrieve a private field
MyReturnType accessiblePrivateField = (MyReturnType) accessor.GetField( "privateFieldName" );

// Call a private method
accessor.Invoke( "PrivateMethodName", new Object[] {/* ... */} );

Answer 4

Je ne suis pas d'accord avec la philosophie "vous ne devriez vous intéresser qu'aux tests de l'interface externe". C'est un peu comme si l'on disait qu'un atelier de réparation de voitures ne devait faire des tests que pour voir si les roues tournent. Oui, en fin de compte, je suis intéressé par le comportement externe, mais j'aime que mes propres tests internes, privés, soient un peu plus spécifiques et précis. Oui, si je procède à un remaniement, il se peut que je doive changer certains des tests, mais à moins qu'il ne s'agisse d'un remaniement massif, je ne devrai en changer que quelques-uns et le fait que les autres tests internes (inchangés) fonctionnent toujours est un excellent indicateur du succès du remaniement.

Vous pouvez essayer de couvrir tous les cas internes en utilisant uniquement l'interface publique et, théoriquement, il est possible de tester chaque méthode interne (ou du moins toutes celles qui comptent) entièrement en utilisant l'interface publique, mais vous risquez de devoir vous mettre sur la tête pour y parvenir et la connexion entre les cas de test exécutés via l'interface publique et la partie interne de la solution qu'ils sont censés tester peut être difficile ou impossible à discerner. Le fait d'avoir des tests pointus et individuels qui garantissent que la machinerie interne fonctionne correctement vaut bien les changements de test mineurs qui surviennent avec le remaniement - du moins, c'est ce que j'ai constaté. Si vous devez apporter d'énormes changements à vos tests à chaque refactoring, alors peut-être que cela n'a pas de sens, mais dans ce cas, vous devriez peut-être repenser entièrement votre conception. Une bonne conception devrait être suffisamment flexible pour permettre la plupart des changements sans avoir à procéder à des remaniements massifs.

Answer 5

Dans les rares cas où j'ai voulu tester des fonctions privées, je les ai généralement modifiées pour qu'elles soient protégées, puis j'ai écrit une sous-classe avec une fonction d'enveloppe publique.

La classe :

...

protected void APrivateFunction()
{
    ...
}

...

Sous-classe pour les tests :

...

[Test]
public void TestAPrivateFunction()
{
    APrivateFunction();
    //or whatever testing code you want here
}

...