Le produit actuel que je travaille est un service Windows écrit en C ++ et en avançant toutes les nouvelles fonctionnalités aura des tests unitaires écrits pour cela. Mais cela crée un problème intéressant (pour moi au moins), nous faisons beaucoup d'appels Win32 pour diverses choses et se comporter en conséquence, afin que les tests de l'unité soient complètes, il serait agréable de tester une variété de sorties, pas seulement du système actuel. état.
Ma question est la meilleure façon de se moquer des résultats des appels Win32? J'ai pensé à deux méthodes différentes:
1) Mettez tous les appels Win32 utilisés dans les pointeurs de la fonction et les transmettent dans les fonctions ou les classes (en fonction du nombre de fois qu'ils sont touchés) qui les utilisent et utilisez-le pour obtenir des résultats simulés.
2) avoir beaucoup de suis-je complètement hors de la base ici, ou manque une connaissance fondamentale? #Ifdef unittest partout et s'il appelle mes propres méthodes spéciales ou que les normales sont appelées si non.
5 Réponses :
Dans la mesure du possible, il serait préférable de faire que les événements se produisent sans modifier les appels Win32.
Par exemple au lieu de faire votre propre Si vous devez vous moquer de l'appel Win32, il serait probablement préférable de créer une bibliothèque de wrapper autour des ensembles d'appels Win32 que vous souhaitez faire. Ensuite, vous ne nuirez pas au code alphabétisation de la logique principale. Createfile qui échouera car un fichier est utilisé, ouvrez plutôt le fichier avec un autre programme (que vous appelez à partir de votre test de l'unité) puis exécutez le test de l'unité. .
par rapport à (2), la plupart des fonctions Win32 qui prennent des paramètres de chaîne ont déjà leur forme commune définie comme une macro, par exemple. de winuser.h: Vous pouvez certainement ajouter un en-tête à votre projet qui redéfinit les fonctions de l'API que vous souhaitez simuler: En redéfinissant le nom, vous pouvez éviter de dispersion beaucoup de compilation conditionnelle dans votre code source.
C'était ma pensée sur la façon de le faire. Je voudrais éviter de changer vos signatures de fonction afin de faire des tests unitaires.
Utilisez Deviare API Crochet et intercepter tous les appels de l'API et Faites votre test de l'unité.
Je recommanderais d'encapsuler les appels de l'API dans des interfaces bien facturées. Ensuite, vous pouvez tester votre logique commerciale en utilisant des objets simulés ou des tests de test. Vous n'avez pas besoin de tester l'API Windows elle-même parce que cela se fait déjà par des millions d'applications Windows Windows.
Un test unitaire ne doit jamais impliquer un accès matériel si vous ne développez pas de matériel. Il s'agit juste de tester votre code logique.
En fin de compte, j'ai effectivement pris plus d'une approche C # et créé des interfaces qui me permettraient d'encercler les appels Win32 que je voulais utiliser.
Par exemple, j'en ai eu un appelé (Je ne sais pas si c'est une mauvaise étiquette pour répondre à ma propre question) iregyRoperations qui contenait regopenKey , regêtrevalueeex , regnotifyChange et plusieurs autres que j'étais utilisant. Une valeur par défaut qui appelle simplement la fonction réelle a été créée dans le constructeur, mais j'ai également eu un constructeur qui a pris l'interface afin que je puisse simuler des valeurs non valides, etc.
Et si vous avez besoin d'arguments afin de modifier le comportement de l'unitestMessagebox? #Ifdef Unittest #undef messagebox #define MessageBox UnitestMessageBox #undIf