J'ai une classe avec une méthode publique Send()et quelques méthodes privées. Il appelle quelques services Web et traite la réponse. Le traitement se fait dans des méthodes privées.
Je veux tester le code à l'unité. Je crois comprendre que les tests unitaires devraient tester mon code de manière isolée (c'est-à-dire simuler les réponses des fournisseurs).
Je crois également que les méthodes privées ne devraient pas avoir besoin d'être testées à l'unité. Mais si je teste simplement la méthode Send (), mon code n'est pas testé de manière isolée et dépend de la réponse du fournisseur.
Dois-je alors rendre mes méthodes privées publiques afin de pouvoir les tester avec des réponses factices? Cela semble une mauvaise pratique car seule la classe devrait avoir besoin de les appeler.
Toutes mes excuses si c'est une question fondamentale, je suis assez nouveau pour les tests unitaires.
J'utilise c # et VS2010
la source
Réponses:
Vous devez séparer le code traitant des services Web (c'est-à-dire l'envoi et la réception de données) du code traitant les résultats. Déplacez ce dernier code dans une classe distincte, en rendant publiques les méthodes nécessaires. Ensuite, vous pouvez facilement tester de manière unitaire la logique de traitement, indépendamment des dépendances externes.
Par cela, vous rendez également votre code conforme au principe de responsabilité unique . En règle générale, ressentir le besoin de tester des méthodes privées est souvent une indication que la classe a trop de responsabilités et devrait donc être refactorisée en plusieurs classes.
la source
Je pense qu'un test avec de telles dépendances ( appeler les services Web des fournisseurs ) est un test d'intégration plutôt qu'un test unitaire.
la source
Comme d'autres l'ont dit, si vos tests unitaires ont des dépendances externes comme des services Web ou des appels de base de données, ce ne sont PAS du tout des tests unitaires, ce sont des tests d'intégration.
Les vrais tests unitaires peuvent s'exécuter indépendamment des composants externes, à l'exception du composant qu'ils sont destinés à tester et doivent être reproductibles quel que soit l'environnement. Si les services Web externes tombent en panne, votre test unitaire ne devrait pas échouer.
Nous contournons cela en utilisant un cadre de simulation. Les objets fantômes nous permettent de créer une maquette d'un composant afin que le composant de notre test unitaire utilise ces objets fantômes au lieu de vrais. Nous pouvons injecter des objets fictifs dans le composant testable, et spécifier quel (s) argument (s) nous attendons, ce que nous voudrions qu'il retourne quand il est appelé, même quelle exception nous voudrions qu'il lance. Je recommande fortement de lire davantage sur le sujet car cela améliorera la fiabilité et l'indépendance de vos tests unitaires.
Pour une bonne publication sur différents frameworks de simulation C #, voir le thread SO suivant:
/programming/37359/what-c-mocking-framework-to-use
EDIT: Pour les personnes ouvertement sensibles, je reconnais que j'ai négligé de mentionner DbUnit ou d'autres outils transactionnels qui peuvent annuler les modifications de la base de données à la fin du test. Celles-ci sont également reproductibles et peuvent être indépendantes de l'environnement avec les données de test générées, un cadre de simulation n'est donc pas nécessaire dans ce cas.
la source