Si nous testons une fonction B, en testant une fonction C qui appelle cette fonction B, c'est-à-dire en écrivant un programme de test pour tester la fonction C qui appelle cette fonction B, la méthode de test est-elle toujours appelée test unitaire, ou autre chose?
Quand est-il préférable de tester indirectement sur une fonction qui appelle la fonction cible, et quand est-il préférable de tester directement une fonction?
Une définition populaire du test unitaire est celle de l'ISTQB:
Un test unitaire est la plus petite partie testable d'une application comme les fonctions, les classes, les procédures, les interfaces. Les tests unitaires sont une méthode par laquelle des unités individuelles de code source sont testées pour déterminer si elles sont aptes à l'utilisation.
Selon cette définition:
Il peut maintenant y avoir une différence entre l'intention et la portée du test. Si vous écrivez un programme de test pour B en utilisant C, il s'agit toujours d'un test unitaire de C, car tout ce que vous pouvez faire est de fournir l'entrée à C et de vérifier en fonction de la sortie si B était correct. C'est juste que vous en déduisez que B fonctionne parce que C fonctionne.
Il existe également une définition de test d'intégration :
Tests effectués pour exposer les défauts des interfaces et des interactions entre composants ou systèmes intégrés.
La définition habituelle des composants logiciels implique qu'ils sont indépendants et peuvent être déployés seuls. Ici, B et C ne semblent pas être des composants indépendants, nous n'avons donc pas de test d'intégration.
Cela dépend beaucoup de ce que vous considérez comme une unité. Si Cc'est si simple que le tester séparément n'a pas de sens, alors votre test est un test unitaire.
Il est beaucoup plus important pour votre suite de tests unitaires pour une unité particulière d'avoir une couverture de ligne proche de 100% et de tester tous les chemins de code pratiquement prévus.
Oui, nous l'appelons toujours un test unitaire si la fonction appelle d'autres fonctions.
Les tests unitaires devraient tester le comportement public d'une classe et non les implémentations privées. Comme suggéré par ce test de Google sur l'article de toilette .
Si vous suivez les règles du Clean Code, vos fonctions ne devraient pas dépasser 4 lignes de code. Cela rend impossible de ne pas tester une autre fonction privée avec vos tests unitaires.
Pourquoi ne devriez-vous pas tester séparément la plupart des fonctions privées? Parce que refactoring vous obligerait à continuer de mettre à jour tous vos tests unitaires d'implémentation. Cela deviendra frustrant lorsque vous en aurez beaucoup, alors que le comportement du public ne devrait pas changer pendant la refactorisation et donc le test ne devrait pas avoir besoin de mise à jour. Vous devriez pouvoir tester des soldats privés avec leur parent public. Parfois, il peut être utile de tester des cours privés complexes, mais vous vous demandez s'ils devraient être une classe distincte par eux-mêmes?
Test d'intégration :
Maintenant, si la fonction fait partie d'une autre classe, c'est différent. Nous l'appellerions alors test de composants ou test d'intégration. Vous intégrez plusieurs classes et exécutez un test contre elles. La fonction B dépendrait de la fonction C. Pour pouvoir tester la fonction B, vous pouvez utiliser l' injection de dépendance pour isoler la fonction que vous testez, ce serait à nouveau un test unitaire.