Comment créer des tests unitaires si la méthode ou la procédure que je teste contre des comptes sur un morceau de code d'une tierce partie? Dites, j'ai une méthode qui utilise des cours d'une source tierce qui nécessite une configuration qui ne peut être effectuée que dans un test fonctionnel. Comment dois-je m'approcher? La plupart du temps, la dépendance de la troisième partie ne peut pas être moquée, mais ma méthode a vraiment besoin de l'utiliser.
Aussi, devrais-je éviter mes tests d'unité ou même mes tests fonctionnels d'exploiter des données réelles? Comme mes tests, si mes tests ne se connectent jamais à une API de base de données pour ajouter temporairement des données, fonctionnent et testez-la, puis supprimez-la ensuite?
3 Réponses :
Généralement, il est supposé que le logiciel tiers est testé et cela fonctionne bien. Bien que cela puisse vous surprendre lorsque vous découvrez un bogue.
Cela dépend de ce que vous êtes des tests unitaires. Certaines choses, comme par exemple l'accès à un morceau de matériel exotique ou de ressource, ou une simple connexion réseau, ne doit pas être testé unitaire. Pour de tels appels, nous utilisons des simulacres et ne les testons pas.
Pour les bases de données, vous pouvez utiliser des simulacres, au lieu de classes réelles pour accéder à la base de données. Ou, vous pouvez créer une base de données en mémoire dans la méthode de configuration du test de l'unité et les détruire dans le nettoyage.
tests unitaires
Vous devriez tout tester. Mais tout n'utilise pas des tests d'unité. Les tests unitaires ne dépendent pas de l'environnement - de la base de données, de la connexion Internet, etc. Les meilleures pratiques pour travailler avec des outils 3rd Parties non conçues / instables consistent à créer une couche anti-corruption entre votre code et votre code tiers. Donc, refactorisez votre code pour rendre votre logique professionnelle aussi indépendante que possible. et testez la logique commerciale.
Si vous n'êtes pas sûr de la manière dont le code tiers fonctionne ou s'il change à l'avenir, vous pouvez faire des tests d'apprentissage. Ce sont des tests d'unité (si possible) qui affirment le comportement que vous comptez sur. Dans les tests d'apprentissage, vous ne testez que le code 3ème partie, pas le vôtre
Si le code tiers est de plus en moins de confiance (bibliothèques ouvertes bien connues), vous supposez que cela fonctionne, ne faites pas de séparation et que vous testez uniquement votre code, pas les bibliothèques.
tests non-unités
Si vos tests nécessitent un environnement externe (DB, réseau, etc.), vous devez effectuer des tests d'intégration. Son objectif n'est pas de tester la logique commerciale mais que si vous avez correctement connecté toutes les pièces correctement. Le test SQL est l'une des exceptions les plus célèbres.
Il n'y a pas de règle simple Comment faire des tests d'intégration (vous pouvez écrire des livres sur les tests SQL). Cela dépend de ce que vous voulez tester exactement, la quantité de similarité pour votre environnement de production dont vous avez besoin / souhaitez. Par exemple, vous pouvez effectuer des tests SQL contre la mémoire DB en mémoire ou contre votre dB de production (Oracle, Postgres, etc.). Cependant, vous concevez vos tests d'intégration, vous devez assurer que chaque test commence par l'état de l'environnement Connaissance. et vous avez pris connaissance des erreurs qui laisse un environnement dans l'état sale et la vitesse de ces tests
Merci d'avoir mentionné des couches anti-corruption. Maintenant, je comprends ce que j'essaie de chercher.
Vous avez dit: