cmake et tests unitaires

Version imprimable

Hé oui, me revoilà ! ;)

J'essaie de suivre les recommandations qui m'ont été données il y a quelques temps, ie utiliser boost test et cmake pour les tests unitaires de ma petite bibliothèque header-only. Cmake m'a posé quelques soucis mais après quelques tutos j'ai fini par (entre)voir comment ça marchait, en tout cas suffisamment pour écrire un CmakeList.txt capable de faire tourner un seul test boost tout simplet. Maintenant je bloque sur la structure générale à donner aux tests et au projet Cmake.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 ma_lib \_ modules \_ moduleA \_ A1.h \_ A2.h \_ moduleB \_ B.h \_ test \_ integration_test \_ unit_test \_ ma_lib.h #include tous les headers des tous les modules de la lib
Première question : où est-ce que je mets le(s) script CmakeList.txt ? J'imaginais mettre le script suivant dans le dossier ma_lib/test:

Citation:

cmake_minimum_required(VERSION 3.0)
project(ma_lib_test)
add_subdirectory(unit_test)
add_subdirectory(integration_test)

et puis dans chaque sous dossier integration_test et unit_test mettre à nouveau un CmakeList.txt du genre
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 cmake_minimum_required(VERSION 3.10) #ai-je besoin de redéfinir ça ? FIND_PACKAGE(Boost) IF (Boost_FOUND) INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIR}) ADD_DEFINITIONS( "-DHAS_BOOST" ) ENDIF() FIND_PACKAGE(GDAL) IF (GDAL_FOUND) INCLUDE_DIRECTORIES(${GDAL_INCLUDE_DIR}) ENDIF() # creates the executable add_executable(integration integration.cpp)
Cela vous paraît-il correct ? J'imagine que non :mouarf: ?

Une autre petite question, comment rendre compte des dépendances à ma_lib dans les scripts de test ? Une directive #include "../../../ma_lib/ma_lib.h" me paraît pas topissime, n'est-ce pas ?

Une (dernière, promis) question: faut-il dans les tests unitaires rendre compte de la structure des modules de la lib, en mettant une hiérarchie de dossiers modules/module1/sousmodule1A etc ? Si oui, comment Cmake s'inscrit là dedans ?

Voili voilou, encore une fois désolé si tout ça tient de l'évidence ahaha mais j'ai du mal à trouver ce genre d'info générale sur *un moteur de recherche parmi les autres* :)
En vous remerciant d'avance,
Seab

17/09/2018, 20h42
Invité

Salut

Je vais donner des réponses en vrac donc désolé si c'est un peu décousu.

C'est CMakeLists.txt pas CmakeList.txt.

Pour la version de cmake, mets la plus vieille version compatible avec ton CMakeLists.txt, sinon plein de gens ne pourront pas compiler ton projet car leur cmake est trop vieux (alors que tu n'as probablement pas besoin des dernières nouveautés de cmake). Mettre 2.8 ou même 2.6 n'a rien de choquant...

Pour les add_directory + CMakeLists.txt multiples, perso je te conseille de laisser tomber et de mettre toute ta config dans un unique CMakeLists.txt à la racine de ton projet. add_directory c'est bien si tu inclus un sous-module git qui est déjà configuré avec cmake mais pour un projet unique pas trop gros, je trouve que ça complique inutilement.

Pour inclure boost test, je crois qu'il faut plutôt faire "find_package(Boost COMPONENTS system unit_test_framework REQUIRED)".

Le ADD_DEFINITIONS m'étonne un peu. C'est vraiment nécessaire ?

Pour le add_executable, il ne manque pas un target_link_libraries pour ajouter gdal. Ou alors gdal est header-only ?

Pour inclure ta lib dans le code de test, il suffit d'ajouter "include_directories( ./ )" dans le CMakeLists.txt et de mettre un "#include <ma_lib/ma_lib.h>" dans les codes de test (ou, plus généralement, qui utilisent ta lib).

Pour l'emplacement du code de test, il y a un peu les 2 écoles : soit mettre le fichier de test à côté du fichier source, soit faire un dossier pour les tests complètement à part. L'important, c'est que le code de test ne soit pas installé dans la lib finale. D'ailleurs dans le CMakeLists.txt, ce serait bien de mettre aussi une directive pour l'install.

Une dernière remarque : pourquoi faire du header-only ? Le header-only c'est une bonne idée dans des cas très spécifiques mais ça a pas mal d'inconvénients (temps de compilation notamment). Les lib classiques sont super faciles à faire avec cmake donc autant en profiter...
17/09/2018, 21h21
Seabirds

Merci Simon de ta réponse !

Citation:

Envoyé par SimonDecoline

Je vais donner des réponses en vrac donc désolé si c'est un peu décousu.

A cheval offert on ne regarde pas les dents :hola:

Citation:

Envoyé par SimonDecoline

Pour les add_directory + CMakeLists.txt multiples, perso je te conseille de laisser tomber et de mettre toute ta config dans un unique CMakeLists.txt à la racine de ton projet. add_directory c'est bien si tu inclus un sous-module git qui est déjà configuré avec cmake mais pour un projet unique pas trop gros, je trouve que ça complique inutilement.

C'est bon a savoir! Merci!

Citation:

Envoyé par SimonDecoline

Pour inclure boost test, je crois qu'il faut plutôt faire "find_package(Boost COMPONENTS system unit_test_framework REQUIRED)".

Heu comme je suis un gros flemmard j'utilise la version header-only.

Citation:

Envoyé par SimonDecoline

Le ADD_DEFINITIONS m'étonne un peu. C'est vraiment nécessaire ?

La magie de copier-coller des bouts de code trouver en ligne: tu rajoutes, tu essaies de comprendre qui fais quoi, tu bidouilles, et quand ça marche tu touches plus. Consequemment je n'ai aucune idée de ce que fais ADD_DEFINITIONS et de si c'est necessaire ou pas. J'ai trouve le bout de code ici: https://stackoverflow.com/questions/...snt-find-boost

Citation:

Envoyé par SimonDecoline

Pour le add_executable, il ne manque pas un target_link_libraries pour ajouter gdal. Ou alors gdal est header-only ?

Oups. Je m'en occupe, merci !

Citation:

Envoyé par SimonDecoline

Pour inclure ta lib dans le code de test, il suffit d'ajouter "include_directories( ./ )" dans le CMakeLists.txt et de mettre un "#include <ma_lib/ma_lib.h>" dans les codes de test (ou, plus généralement, qui utilisent ta lib).

Wooh ok, dis comme ça c'est évident. Merci!

Citation:

Envoyé par SimonDecoline

Pour l'emplacement du code de test, il y a un peu les 2 écoles : soit mettre le fichier de test à côté du fichier source, soit faire un dossier pour les tests complètement à part. L'important, c'est que le code de test ne soit pas installé dans la lib finale. D'ailleurs dans le CMakeLists.txt, ce serait bien de mettre aussi une directive pour l'install.

Une directive pour l'install ... mhhh je crois que j'ai toujours pas compris ce que voulais vraiment dire une installation. Je vais checker ca. ;)

Citation:

Envoyé par SimonDecoline

Une dernière remarque : pourquoi faire du header-only ? Le header-only c'est une bonne idée dans des cas très spécifiques mais ça a pas mal d'inconvénients (temps de compilation notamment). Les lib classiques sont super faciles à faire avec cmake donc autant en profiter...

Bonne question. Comme il y a des templates partout et que le projet est assez riquiqui, les temps de compilations sont pas vraiment un facteur dissuasif (3 secondes ...). Quand je dis ma_lib, au fond c'est que quelques dizaines de classes qui se balladent dans des headers en attendant d’être utiilisées dans des petits main.cpp de 200 lignes.

[EDIT] Tadaaaam c'est bon ça marche bien: les tests plantent à la perfection ! Un immense merci pour ton aide ! :)
18/09/2018, 07h18
koala01
Salut,

A quelques détails près (j'utilise Catch2 comme bibliothèque pour les tests unitaires, et j'inclus cette bibliothèques comme sous module de mon projet), mon repo d'implémentation d'un systeme de signaux et de slot devrais te fournir un exemple efficace ;)

Comme tu le verras dans les CMakefileLists.txt (entre autres ceux qui se trouvent dans le sous-dossiers tests), le principe utilisé est:
- de créer une liste des fichiers qui devront être compilés;
- de compiler chaque fichier séparément, en indiquant la bibliothèque à tester et la bibliothèque de tests unitaire comme dépendance
- de le désigner chaque application créée comme étant un tests unitaire
C'est simple et efficace :D

Nota: L'organisation de ce repos est prévue pour permettre de combiner littéralement plusieurs bibliothèques développées séparément en un projet unique, en évitant les collisions
18/09/2018, 09h58
Seabirds

Ooooh y'a même Doxygen et les exemples d'illustrations oO C'était le point suivant que je comptais aborder :mrgreen:

Bon bah c'est super ça dépanne énormément, merci! :) Je jette un coup d'oeil à Catch2 !
18/09/2018, 15h23
ternel

Je vais regarder aussi, je sens que je vais en avoir besoin…
18/09/2018, 18h36
koala01

En fait, je ne voulais pas (forcément) "faire l'article" pour Catch2, mais, l'un dans l'autre, c'est une bibliothèque simple qui fait le boulot qu'on attend de sa part, et qui est au moins tout aussi facile à prendre en main que boost::unit_tests.

J'ai surtout profité que je n'avais besoin de boost pour rien d'autre pour choisir une bibliothèque de tests unitaires "indépendante". Vous n'êtes absolument pas obligés de suivre cette "lubie" :D

D'autant plus que transformer les CMakeLists.txt pour utiliser boost::unit_test au lieu de Catch2 se fait de manière très simple, et peut parfaitement se justifier, surtout si vous avez déjà besoin d'utiliser boost pour autre chose ;)