Par exemple, voici ce que j'utilise [...] pour les tests.
J’utilise également catch, par contre je ne compile pas du tout de la même façon.
Je définis un seul target, qui compile tous mes tests/*.cpp, et un seul de ces fichiers contient le CATCH_CONFIG_MAIN.
Ça permet de ne pas avoir à compiler plein de fois le main de catch (ce qui prend chez moi 4.3 secondes, pour un fichier « vide » c’est un peu long), et ça me donne un seul binaire sur lequel je peux lancer les tests que je veux juste en passant des arguments.
J’ai fait un peu le même constat avec boost.test : c’est le « main » du framework qui prend (de loin) le plus de temps à compiler. J’ai donc décidé de toujours compiler tous mes tests en un seul binaire, et de mettre la partie « main du framework » dans un fichier rien que pour lui, pour ne jamais avoir à le recompiler quand je modifie simplement un de mes tests.
[^] # Catch et sa compilation
Posté par louiz’ (site web personnel) . En réponse au journal CMake mon amour. Évalué à 3.
J’utilise également catch, par contre je ne compile pas du tout de la même façon.
Je définis un seul target, qui compile tous mes tests/*.cpp, et un seul de ces fichiers contient le CATCH_CONFIG_MAIN.
Ça permet de ne pas avoir à compiler plein de fois le main de catch (ce qui prend chez moi 4.3 secondes, pour un fichier « vide » c’est un peu long), et ça me donne un seul binaire sur lequel je peux lancer les tests que je veux juste en passant des arguments.
J’ai fait un peu le même constat avec boost.test : c’est le « main » du framework qui prend (de loin) le plus de temps à compiler. J’ai donc décidé de toujours compiler tous mes tests en un seul binaire, et de mettre la partie « main du framework » dans un fichier rien que pour lui, pour ne jamais avoir à le recompiler quand je modifie simplement un de mes tests.
(Et puis en plus, ça me parait plus court à écrire : https://git.poez.io/biboumi/tree/CMakeLists.txt#n159 )
Quels sont les avantages de ta méthode, à ton avis ?