Journal Frameworks de test unitaires: retour d'XP

Posté par  (site web personnel) .
Étiquettes :
0
17
août
2006
Suite à l'engouement (hum) généré par mon post dans les forums ( http://linuxfr.org/forums/19/18251.html -
oui, j'ai tenté au moins), je me dis que pour un retour d'expérience, les journaux sont une solution acceptable.

J'aurais donc aimé avoir le témoignage de gens qui ont utilisé un framework de tests unitaires pour des programmes en C (oui, j'ai vu Delarue hier). La wikipedia en donne une petite liste: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks(...)

Je sais par exemple que check est utilisé par gstreamer, mais j'ai vu que gnu autounit était revenu il y a peu à la vie, et puis il y a CUnit qui a l'air d'être assez utilisé... Bref, vous utilisez quoi vous ? Et qu'est ce qui, pour vous, fait qu'un framework est bon ?

  • # IFDEFs de porcs

    Posté par  (site web personnel) . Évalué à 2.

    Personellement, j'utilise depuis longtemps le bon vieux hack du "faux main" (que le GNU utilise aussi, au moins dans la gnulib).
    Concrètement ça donne des trucs genre
    #ifdef DEBUG
    int
    main (void)
    {
    __/* mult */
    __{
    _____assert( 4 == mult(2, 2));
    __}
    }
    #endif

    à la fin de tout les fichiers de code C. Et dans le Makefile :
    %.tests: %.c
    ________$(CC) $(CFLAGS) $(LDLIBS) -DDEBUG $? -o $@
    ________valgrind ./$@
    (à adapter suivant tes dépendances).

    C'est simple, efficace et portable.
    Ça fournit aussi un bon endroit pour mettre des exemples de la manière d'utiliser les fonctions. En plus on peut utiliser les outils standards (gdb, valgrind etc) pour explorer ce qu'il se passe quand un test échoue.

    Après, je suppose que c'est pas adaptés à tout les cas. Mais pour les petits projets c'est parfait.

  • # Utiliser un langage de script ?

    Posté par  (site web personnel) . Évalué à 4.

    Pour la question sur ce qui fait qu'un framework est bon, je pense à * Automatisation des résultats : ça sort en batch un rapport ou il y a OK ou KO sans intervention humaine et sans click dans tous les sens
    * Possibilité de stubber : en fait les tests unitaires ne servent presque à rien si on fait du test fonction par fonction, il prennent beaucoup plus de sens quand on fait des tests au niveau d'un module fonctionnel complet (ça tend vers du test d'intégration), par contre il faut la possibilité de pouvoir remplacer les fonctions appelée par le module testée par des stubs de simulation qui peuvent être relativement complexes (machines d'état, mémorisation...) et on doit être capable de vérifier les parametres d'appel à ces fonctions (à chaque appel) et le nombre d'appel.
    * Possibilité de faire de la couverture (avec aussi le cumul de couverture pour vérifier la couverture obtenue par un ensemble de tests complémentaires)
    * Puissance d'expression des checks : c'est rarement de simples assert sur des boolean même si ça s'y rapporte souvent (mémorisation des valeurs précédantes pour des tests de convergence par exemple)

    Pour la solution pratique, il existe une solution élégantes basée sur l'utilisation d'un langage de script (genre Python) et de générateur de bidding comme Ctypes ou SWIG. Ainsi il n'y a pas besoin de recompiler le code pour faire des tests U mais on peut le faire directement sur les libs du projet. En plus on gagne toute la souplesse et les libraries associées au langage de script. Je n'ai pas en tête de framework qui utilisent cette technique, mais par expérience c'est rapide de s'en faire un maison juste comme il nous convient...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.