Dans quelle mesure testez-vous à l'unité les composants internes / privés d'une classe / module / package / etc? Les testez-vous ou testez-vous simplement l'interface avec le monde extérieur? Un exemple de ces méthodes internes est privé.
Par exemple, imaginez un analyseur de descente récursif , qui a plusieurs procédures internes (fonctions / méthodes) appelées à partir d'une procédure centrale. La seule interface avec le monde extérieur est la procédure centrale, qui prend une chaîne et renvoie les informations analysées. Les autres procédures analysent différentes parties de la chaîne et elles sont appelées à partir de la procédure centrale ou d'autres procédures.
Naturellement, vous devez tester l'interface externe en l'appelant avec des exemples de chaînes et en la comparant avec une sortie analysée à la main. Mais qu'en est-il des autres procédures? Souhaitez-vous les tester individuellement pour vérifier qu'ils analysent correctement leurs sous-chaînes?
Je peux penser à quelques arguments:
Avantages :
- Davantage de tests, c'est toujours mieux, et cela peut aider à augmenter la couverture du code
- Certains composants internes peuvent être difficiles à fournir des entrées spécifiques (cas de bord par exemple) en donnant une entrée à l'interface externe
- Des tests plus clairs. Si un composant interne a un bogue (corrigé), un cas de test pour ce composant indique clairement que le bogue était dans ce composant spécifique
Inconvénients :
- La refactorisation devient trop douloureuse et prend du temps. Pour changer quoi que ce soit, vous devez réécrire les tests unitaires, même si les utilisateurs de l'interface externe ne sont pas affectés
- Certains langages et frameworks de test ne le permettent pas
Quelles sont vos opinions?