Un des avantages du C, c'est que ça s'intègre relativement facilement dans à peu près n'importe quelle pile technologique. Du coup, j'aurais tendance à choisir l'infrastructure de test d'abord. Perso, je n'ai pas eu les moyens de pousser la question autant que j'aurais aimé, mais j'avais testé sur une base de l'infra de tests de libboost en C++ (je n'ai aucun goût pour le C++, et je n'aimerais pas coder sur un projet exclusivement en C++, mais sur de l'infra de test, ça va très bien), et testé aussi sur du Python en ctypes. On peut aussi wrapper vers du java en JNI mais, à mon avis, c'est un chouille plus galère.
Dans tous les cas, ça implique probablement d'ajouter pas mal de helpers dans le code, et donc prévoir des options de compils test/prod (rien que pour tester les fonctions non exportées par exemple). Pour faire de l'intégration continue, faudra aussi expliquer à l'outil comment compiler le code. Du coup, pour évite de recompiler tout à chaque test, il vaut mieux avoir une compilation aussi modulaire que le code lui même.
Dans tous les cas, je déconseille l'écrite d'un framework perso. ça serait dommage de se priver de tout ce qui existe dans le domaine de l'intégration continue (récup des sources, build, lancement auto des campagnes de test, collecte des résultats, ...)
Bon désolé, c'est pas une réflexion très approfondie, mais c'est peut-être quelques pistes. En tout cas, si tu arrives à un truc qui te plait, ça m'intéresse d'avoir un retour.
# agnostique
Posté par gaaaaaAab . En réponse au message Qu'utilisez-vous pour vos tests en C ?. Évalué à 0.
Un des avantages du C, c'est que ça s'intègre relativement facilement dans à peu près n'importe quelle pile technologique. Du coup, j'aurais tendance à choisir l'infrastructure de test d'abord. Perso, je n'ai pas eu les moyens de pousser la question autant que j'aurais aimé, mais j'avais testé sur une base de l'infra de tests de libboost en C++ (je n'ai aucun goût pour le C++, et je n'aimerais pas coder sur un projet exclusivement en C++, mais sur de l'infra de test, ça va très bien), et testé aussi sur du Python en ctypes. On peut aussi wrapper vers du java en JNI mais, à mon avis, c'est un chouille plus galère.
Dans tous les cas, ça implique probablement d'ajouter pas mal de helpers dans le code, et donc prévoir des options de compils test/prod (rien que pour tester les fonctions non exportées par exemple). Pour faire de l'intégration continue, faudra aussi expliquer à l'outil comment compiler le code. Du coup, pour évite de recompiler tout à chaque test, il vaut mieux avoir une compilation aussi modulaire que le code lui même.
Dans tous les cas, je déconseille l'écrite d'un framework perso. ça serait dommage de se priver de tout ce qui existe dans le domaine de l'intégration continue (récup des sources, build, lancement auto des campagnes de test, collecte des résultats, ...)
Bon désolé, c'est pas une réflexion très approfondie, mais c'est peut-être quelques pistes. En tout cas, si tu arrives à un truc qui te plait, ça m'intéresse d'avoir un retour.