Il est destiné aux personnes qui utilisent CUnit comme cadre de test unitaire. ・ Les personnes souhaitant recommander Google Test à leur environnement ・ Les personnes souhaitant passer à Google Test et souhaitant expliquer son utilité aux personnes concernées
Il est destiné aux personnes qui recherchent un framework de test plus facile à utiliser que CUnit, mais je pense que le contenu est mince par rapport aux autres pages. Je connais GoogleTest dans une certaine mesure et je me concentre sur la façon de le recommander à d'autres.
Je pense que l'exemple de code vous donnera une image, mais je la téléchargerai s'il y a un besoin.
GoogleTest, comme CUnit, est un framework de test unitaire. Tous les manuels sont disponibles en ligne (même si je pense que CUnit en a également à cet égard). http://opencv.jp/googletestdocs/primer.html
J'ai téléchargé et utilisé 1.8.0 à partir d'ici. https://github.com/google/googletest/releases
J'ai essayé de les lister dans l'ordre dans lequel je pense que l'effet est excellent du point de vue du développeur. Si vous expliquez dans cet ordre, vous voudrez sûrement l'utiliser. De plus, lors de l'explication de l'utilité à des personnes autres que les développeurs, le point qui «peut être écrit court» du point de vue du chef de projet est l'effort de maintenance du test, et le point que «l'installation est inutile» du point de vue du gestionnaire d'environnement est insisté. Cela peut être un mérite d'être. Nous aborderons également l'utilisation des actifs CUnit existants à la fin de cette page.
・ (Peut-être) Peut être écrit plus court que CUnit ・ J'ai écrit un cas de test mais je n'ai jamais oublié de le mettre ・ Peut être utilisé sans installation ・ Aucune fonction principale requise ・ Une liste de cas de test peut être sortie ・ Seuls les tests spécifiés peuvent être exécutés ・ Les fonctions de configuration et de TearDown peuvent être préparées pour chaque suite de tests (strictement appelée dispositif de test). -Le test désactivé affichera explicitement "Combien de tests ont été désactivés" lorsque le test est exécuté.
Ce qui suit sera expliqué dans l'ordre.
CUnit doit ajouter un traitement de type AddSuite après avoir écrit un cas de test, Il est facile de commettre l'erreur de l'écrire par inadvertance mais de ne pas le tester. Lorsque vous écrivez un scénario de test, Google Test l'inclut automatiquement dans la cible de test.
Il fournit tous les fichiers et en-têtes CPP, donc si vous incluez les paramètres de chemin d'inclusion et CPP dans la cible de construction, vous pouvez l'utiliser sans l'installer dans / usr / local / lib. Utile lorsque vous souhaitez l'essayer et le recommander. La méthode détaillée est mentionnée dans cet article (http://d.hatena.ne.jp/E_Mattsan/20120215/1329311774), mais used-src n'est actuellement pas inclus dans la version Release, ce qui suit est implémenté. J'ai dû.
fuse_gtest_files.py <répertoire de sortie>
Bien sûr, vous pouvez également l'installer et l'utiliser.
Puisque GoogleTest l'a préparé, vous pouvez l'utiliser simplement en l'incluant dans la cible de compilation.
Voir ci-dessous pour plus de détails. http://opencv.jp/googletestdocs/advancedguide.html#adv-listing-test-names http://opencv.jp/googletestdocs/advancedguide.html#adv-running-a-subset-of-the-tests
Dans CUnit, j'ai l'expérience de #if 0 partiellement et d'encombrer la partie où le cas de test est défini.
Voir ci-dessous pour plus de détails. http://opencv.jp/googletestdocs/primer.html#primer-test-fixtures
Quel type d'initialisation les cas de test de cette suite de tests doivent-ils être en premier, quel type de nettoyage doit être effectué? Je pense que ce sera plus facile à lire car vous pouvez écrire cela dans la déclaration de la suite de tests.
Voir ci-dessous pour plus de détails. http://opencv.jp/googletestdocs/advancedguide.html#adv-temporarily-disabling-tests
Si c'est #if 0, il peut être oublié un jour. Cependant, dans le cas de "Ce sera NG car il n'est pas implémenté maintenant. Mais j'ai fait un test pour le moment, donc je veux le tester une fois qu'il sera implémenté" Je pense que c'est une bonne idée de le régler sur "test d'invalidation explicite".
Nécessite des connaissances en C ++, mais seulement la capacité de définir des classes et des connaissances super rudimentaires telles que extern "C". Je ne peux penser à aucun inconvénient avec CUnit.
-Besoin de spécifier -lpthread -J'ai construit le source cpp avec gcc au lieu de g ++
Il semble y avoir diverses fonctions utiles, mais si le développeur les utilise trop librement, des tests délicats seront créés ou ils seront hors de contrôle, il est donc préférable de décider quelles fonctions doivent être utilisées et lesquelles ne doivent pas l'être.
Qu'advient-il des cas de test écrits dans CUnit après la migration vers Google Test? Vous le jetez? Je pense que la question sera toujours posée par le manager. Dès la conclusion, il est impossible de le détourner avec zéro main d'œuvre, mais il peut être utilisé avec une petite modification mécanique. Si vous continuez à faire des tests dans le futur, vous pouvez expliquer que c'est un investissement qui peut être récupéré par le montant de l'efficacité de production accrue.
Certaines modifications doivent être apportées aux cas de test basés sur CUnit. J'écrirai en détail s'il y a un besoin, mais notez ce que j'ai fait.
Supprimer ou désactiver la fonction principale, le traitement AddSuite, AddTestCase, etc.
void testcase01(void){
À
TEST(testcase01){
Ou
TEST_F(testName, testcase01){
Cela sera surchargé en fonction du nombre de cas de test. C'est un travail mécanique, il semble donc que vous puissiez le faire avec un script etc., mais si vous ne pouvez pas vous consacrer à ce travail de remplacement, renoncez ...
#define CU_ASSERT EXPECT_TRUE
#include "testCaseForCUnit.c"
Pour Google Test.
Je l'ai écrit en pensant que ce n'était pas nécessaire, alors je pense qu'il y a des points difficiles à comprendre. Donnez-moi un exemple de code! Je vais le mettre à jour s'il y a quelque chose comme ça. Veuillez me pardonner pour le premier message ...