Les tests unitaires des méthodes privées

Question

Je suis dans le processus de l'écriture de l'écriture de tests unitaires. En particulier, je veux tester des méthodes privées.

Jusqu'à présent, la j'en suis venu avec l'aide de.

#define private public

Mais je ne suis pas heureux de ce qu'il va détruire tous encapsulation du point de vue de l'unité de test.

Quelles méthodes utilisez-vous pour des tests unitaires méthodes privées.

Answer 1

Plutôt que le méchant #define hack vous mentionnez dans votre question, un nettoyeur de mécanisme est de faire le test d'un ami de la classe sous test. Cela permet au code de test (et juste le code de test) accès pour les simples soldats, tout en les protégeant de tout le reste.

Cependant, il est préférable de tester par le biais de l'interface publique. Si votre classe X a beaucoup de code dans le privé, les fonctions de membre alors il pourrait être utile à l'extraction d'une nouvelle classe Y, qui est utilisé par la mise en œuvre de la classe X. Cette nouvelle classe Y peut ensuite être testé par le biais de son interface publique, sans exposer son utilisation pour les clients de la classe X.

Answer 2

Si vous utilisez Google Test, vous pouvez utiliser FRIEND_TEST facilement déclarer votre installation de test, comme un ami de la classe sous test.

Et vous savez, si les tests des fonctions privées ont été sans équivoque mauvais comme certains des autres réponses ont dit, alors il ne serait probablement pas être intégrées dans Google Test.

Vous pouvez lire plus à ce sujet lors de l'essai des fonctions privées est bon ou mauvais dans cette réponse.

Answer 3

Si les méthodes sont suffisamment complexes pour justifier test dans l'isolation, puis refactoriser dans leur propre classe(s) et de tester via leur interface publique(s). Ensuite les utiliser à titre privé dans la classe d'origine.

Answer 4

Faire le test de la classe comme l'ami de la classe d'origine. Cet ami déclaration sera à l'intérieur de la #define UNIT_TEST drapeau.

class To_test_class {

....

#ifdef UNIT_TEST

ami test_class;

#endif

} Maintenant, pour votre unité de test vous permettra de compiler le code avec le drapeau-D__UNITAIRE_TEST__. De cette façon, vous serez en mesure de tester la fonction privée.

Maintenant, votre code de test unitaire ne sera pas poussé dans l'environnement de production, comme l' __UNITAIRE__TEST_ drapeau sera fausse. D'où le code est toujours en sécurité.

Aussi, vous n'aurez pas besoin de bibliothèque spéciale pour les tests unitaires.

Answer 5

Le hack est une idée horrible. Arbitrairement la ré-écriture de votre code avec le préprocesseur quand vous allez à la compilation il n'est jamais sage.

Maintenant, comme plusieurs personnes l'ont déjà mentionné, on peut se demander si l'on doit mettre à l'essai des méthodes privées. Mais cela ne couvre pas le cas où vous avez intentionnellement caché des constructeurs pour limiter instantiaton à certaines étendues, ou quelques autres plus ésotérique des cas.

Aussi, vous ne pouvez pas l'ami d'un espace de noms et de "l'amitié" n'est pas hérité en C++ donc, en fonction de votre framework de test unitaire, vous pourriez être en difficulté. Heureusement, si vous utilisez le Boost.De Test, il n'y a de solution élégante à ce problème sous la forme de Montages.

http://www.boost.org/doc/libs/1_52_0/libs/test/doc/html/utf/user-guide/fixture/per-test-case.html

Vous pouvez ami de l'appareil et l'avoir à instancier toutes les instances que vous utilisez dans votre unité de fonctions de test, les déclarant comme de l'électricité statique à l'appareil et à portée de module. Si vous utilisez un espace de noms ne vous inquiétez pas, vous pouvez simplement déclarer votre appareil dans l'espace de noms et vos cas de test à l'extérieur de l'espace de noms, et ensuite utiliser l'opérateur de résolution de portée pour se rendre à la statique des membres.

L' BOOST_FIXTURE_TEST_CASE macro va prendre soin de l'instanciation et la déchirure en bas de votre appareil pour vous.