Code C des tests unitaires [fermé]

Cet été, j'ai travaillé sur un système embarqué écrit en droite C. C'était un projet existant que l'entreprise pour laquelle j'avais travaillé avait repris. Je me suis habitué à écrire des tests unitaires en Java à l'aide de JUnit, mais j'étais à court de la meilleure façon d'écrire des tests unitaires pour le code existant (qui avait besoin d'une refactorisation) ainsi que le nouveau code ajouté au système.

Existe-t-il des projets qui rendent les tests unitaires de code C simple aussi simples que les tests unitaires de code Java avec JUnit? Toute idée qui s'appliquerait spécifiquement au développement embarqué (compilation croisée sur la plate-forme arm-linux) serait grandement appréciée.

Un cadre de test unitaire en C est Check ; une liste des frameworks de tests unitaires en C peut être trouvée ici et est reproduite ci-dessous. Selon le nombre de fonctions de bibliothèque standard de votre runtime, vous pouvez ou non utiliser l'une d'entre elles.

AceUnit

AceUnit (Advanced C et Embedded Unit) se présente comme un cadre de test unitaire de code C confortable. Il essaie d'imiter JUnit 4.x et inclut des capacités de réflexion. AceUnit peut être utilisé dans des environnements de contraintes de ressources, par exemple le développement de logiciels intégrés, et surtout, il fonctionne correctement dans des environnements où vous ne pouvez pas inclure un seul fichier d'en-tête standard et ne pouvez pas invoquer une seule fonction C standard à partir des bibliothèques ANSI / ISO C. Il dispose également d'un port Windows. Il n'utilise pas de fourches pour intercepter les signaux, bien que les auteurs aient exprimé leur intérêt à ajouter une telle fonctionnalité. Voir la page d'accueil AceUnit .

GNU Autounit

Dans la même veine que Check, y compris le fait d'exécuter des tests unitaires dans un espace d'adressage séparé (en fait, l'auteur original de Check a emprunté l'idée à GNU Autounit). GNU Autounit utilise largement GLib, ce qui signifie que la liaison et autres ont besoin d'options spéciales, mais cela peut ne pas être un gros problème pour vous, surtout si vous utilisez déjà GTK ou GLib. Voir la page d'accueil de GNU Autounit .

cUnit

Utilise également GLib, mais ne fourche pas pour protéger l'espace d'adressage des tests unitaires.

CUnit

Standard C, avec des plans pour une implémentation de l'interface graphique Win32. Actuellement, ne bifurque pas ou ne protège pas l'espace d'adressage des tests unitaires. Au début du développement. Voir la page d'accueil de CUnit .

CuTest

Un cadre simple avec un seul fichier .c et un fichier .h que vous déposez dans votre arborescence source. Voir la page d'accueil de CuTest .

CppUnit

Le premier framework de tests unitaires pour C ++; vous pouvez également l'utiliser pour tester le code C. Il est stable, activement développé et possède une interface graphique. Les principales raisons de ne pas utiliser CppUnit pour C sont d'abord qu'il est assez grand, et ensuite vous devez écrire vos tests en C ++, ce qui signifie que vous avez besoin d'un compilateur C ++. Si cela ne ressemble pas à des préoccupations, cela vaut vraiment la peine d'être pris en compte, avec d'autres cadres de test unitaire C ++. Voir la page d'accueil de CppUnit .

embUnit

embUnit (Embedded Unit) est un autre cadre de test unitaire pour les systèmes embarqués. Celui-ci semble être remplacé par AceUnit. Page d'accueil de l'unité intégrée .

MinUnit

Un ensemble minimal de macros et c'est tout! Le but est de montrer à quel point il est facile de tester votre code à l'unité. Voir la page d'accueil de MinUnit .

Unité pour M. Ando

Une implémentation CUnit qui est assez nouvelle, et apparemment encore au début du développement. Voir la page d'accueil de CUnit pour M. Ando .

Cette liste a été mise à jour pour la dernière fois en mars 2008.

Plus de cadres:

CMocka

CMocka est un framework de test pour C avec prise en charge des objets fictifs. Il est facile à utiliser et à configurer.

Voir la page d'accueil de CMocka .

Critère

Criterion est un framework de tests unitaires C multiplateforme prenant en charge l'enregistrement automatique des tests, les tests paramétrés, les théories et qui peut sortir en plusieurs formats, y compris TAP et JUnit XML. Chaque test est exécuté dans son propre processus, de sorte que les signaux et les plantages peuvent être signalés ou testés si nécessaire.

Voir la page d' accueil de Criterion pour plus d'informations.

HWUT

HWUT est un outil général de test unitaire avec un grand support pour C. Il peut aider à créer des Makefiles, générer des cas de test massifs codés dans des `` tables d'itération '' minimales, marcher le long des machines d'état, générer des stubs C et plus encore. L'approche générale est assez unique: les verdicts sont basés sur «bonne sortie / mauvaise sortie». Cependant, la fonction de comparaison est flexible. Ainsi, tout type de script peut être utilisé pour la vérification. Il peut être appliqué à n'importe quelle langue pouvant produire une sortie standard.

Voir la page d'accueil HWUT .

CGreen

Un cadre de test et de simulation unitaire moderne et portable en plusieurs langues pour C et C ++. Il offre une notation BDD en option, une bibliothèque de simulation, la possibilité de l'exécuter en un seul processus (pour faciliter le débogage). Un lanceur de test qui découvre automatiquement les fonctions de test est disponible. Mais vous pouvez créer votre propre programme.

Toutes ces fonctionnalités (et plus) sont expliquées dans le manuel CGreen .

Wikipedia donne une liste détaillée des frameworks de tests unitaires C sous Liste des frameworks de tests unitaires: C

Personnellement, j'aime le framework Google Test .

La vraie difficulté de tester le code C est de casser les dépendances sur les modules externes afin que vous puissiez isoler le code en unités. Cela peut être particulièrement problématique lorsque vous essayez d'obtenir des tests sur du code hérité. Dans ce cas, je me retrouve souvent à utiliser l'éditeur de liens pour utiliser les fonctions de stubs dans les tests.

C'est à cela que les gens font référence lorsqu'ils parlent de " coutures ". En C, votre seule option est vraiment d'utiliser le pré-processeur ou l'éditeur de liens pour simuler vos dépendances.

Une suite de tests typique dans l'un de mes projets C pourrait ressembler à ceci:

#include "myimplementationfile.c"
#include <gtest/gtest.h>

// Mock out external dependency on mylogger.o
void Logger_log(...){}

TEST(FactorialTest, Zero) {
    EXPECT_EQ(1, Factorial(0));
}

Notez que vous incluez réellement le fichier C et non le fichier d'en-tête . Cela donne l'avantage d'accéder à tous les membres de données statiques. Ici, je moque mon enregistreur (qui peut être dans logger.o et donne une implémentation vide. Cela signifie que le fichier de test se compile et se lie indépendamment du reste de la base de code et s'exécute de manière isolée.

Quant à la compilation croisée du code, pour que cela fonctionne, vous avez besoin de bonnes installations sur la cible. Je l'ai fait avec googletest cross compilé sur Linux sur une architecture PowerPC. Cela a du sens car vous disposez d'un shell complet et d'un système d'exploitation pour recueillir vos résultats. Pour les environnements moins riches (que je classe comme étant sans système d'exploitation complet), vous devez simplement créer et exécuter sur l'hôte. Vous devez quand même le faire pour pouvoir exécuter les tests automatiquement dans le cadre de la génération.

Je trouve que tester le code C ++ est généralement beaucoup plus facile car le code OO est en général beaucoup moins couplé que procédural (bien sûr, cela dépend beaucoup du style de codage). Également en C ++, vous pouvez utiliser des astuces comme l'injection de dépendances et la substitution de méthode pour obtenir des coutures dans du code autrement encapsulé.

Michael Feathers a un excellent livre sur les tests de code hérité . Dans un chapitre, il couvre les techniques de gestion du code non OO que je recommande vivement.

Edit : J'ai écrit un article de blog sur le code procédural de test unitaire, avec la source disponible sur GitHub .

Edit : Il y a un nouveau livre qui sort des programmeurs pragmatiques qui traite spécifiquement du code C de test unitaire que je recommande fortement .

Minunit est un cadre de test unitaire incroyablement simple. Je l'utilise pour tester le code du microcontrôleur unitaire c pour avr.

J'utilise actuellement le framework de test unitaire CuTest:

http://cutest.sourceforge.net/

Il est idéal pour les systèmes embarqués car il est très léger et simple. Je n'ai eu aucun problème à le faire fonctionner sur la plate-forme cible ainsi que sur le bureau. En plus d'écrire les tests unitaires, il suffit de:

• un fichier d'en-tête inclus partout où vous appelez les routines CuTest
• un seul fichier 'C' supplémentaire à compiler / lier à l'image
• du code simple ajouté à main pour configurer et appeler les tests unitaires - je l'ai juste dans une fonction principale () spéciale qui est compilée si UNITTEST est défini pendant la construction.

Le système doit prendre en charge un tas et certaines fonctionnalités stdio (que tous les systèmes intégrés ne possèdent pas). Mais le code est assez simple pour que vous puissiez probablement travailler dans des alternatives à ces exigences si votre plate-forme ne les a pas.

Avec une utilisation judicieuse des blocs externes "C" {}, il prend également très bien en charge le test du C ++.

Je dis presque la même chose que ratkok mais si vous avez une touche intégrée aux tests unitaires, alors ...

Unity - Cadre hautement recommandé pour les tests unitaires du code C.

Les exemples dans le livre mentionné dans ce thread TDD pour le C intégré sont écrits en utilisant Unity (et CppUTest).

Vous voudrez peut-être également jeter un œil à libtap , un framework de test C qui génère le protocole TAP (Test Anything Protocol) et s'intègre donc bien avec une variété d'outils proposés pour cette technologie. Il est principalement utilisé dans le monde des langues dynamiques, mais il est facile à utiliser et devient très populaire.

Un exemple:

#include <tap.h>

int main () {
    plan(5);

    ok(3 == 3);
    is("fnord", "eek", "two different strings not that way?");
    ok(3 <= 8732, "%d <= %d", 3, 8732);
    like("fnord", "f(yes|no)r*[a-f]$");
    cmp_ok(3, ">=", 10);

    done_testing();
}

Il existe un élégant cadre de tests unitaires pour C avec prise en charge des objets fictifs appelés cmocka . Il ne nécessite que la bibliothèque C standard, fonctionne sur une gamme de plates-formes informatiques (y compris embarquées) et avec différents compilateurs.

Il prend également en charge différents formats de sortie de message tels que les rapports Subunit, Test Anything Protocol et jUnit XML.

cmocka a été créé pour fonctionner également sur des plates-formes intégrées et prend également en charge Windows.

Un test simple ressemble à ceci:

#include <stdarg.h>
#include <stddef.h>
#include <setjmp.h>
#include <cmocka.h>

/* A test case that does nothing and succeeds. */
static void null_test_success(void **state) {
    (void) state; /* unused */
}

int main(void) {
    const struct CMUnitTest tests[] = {
        cmocka_unit_test(null_test_success),
    };
    return cmocka_run_group_tests(tests, NULL, NULL);
}

L' API est entièrement documentée et plusieurs exemples font partie du code source.

Pour commencer avec cmocka, vous devriez lire l'article sur LWN.net: Test unitaire avec des objets fictifs en C

cmocka 1.0 est sorti en février 2015.

Je n'ai pas été loin de tester une ancienne application C avant de commencer à chercher un moyen de se moquer des fonctions. J'avais vraiment besoin de moqueries pour isoler le fichier C que je veux tester des autres. J'ai essayé cmock et je pense que je l'adopterai.

Cmock analyse les fichiers d'en-tête et génère des fonctions de simulation en fonction des prototypes qu'il trouve. Mocks vous permettra de tester un fichier C dans une parfaite isolation. Tout ce que vous aurez à faire est de lier votre fichier de test avec des maquettes au lieu de vos vrais fichiers objets.

Un autre avantage de cmock est qu'il validera les paramètres passés aux fonctions simulées et vous permettra de spécifier la valeur de retour que les simulations doivent fournir. Ceci est très utile pour tester différents flux d'exécution dans vos fonctions.

Les tests comprennent les fonctions testA (), testB () typiques dans lesquelles vous créez des attentes, appelez des fonctions pour tester et vérifier les assertions.

La dernière étape consiste à générer un runner pour vos tests à l'unité. Cmock est lié au cadre de test d'unité. Unity est aussi facile à apprendre que tout autre framework de test unitaire.

Vaut la peine d'être essayé et assez facile à saisir:

http://sourceforge.net/apps/trac/cmock/wiki

Mise à jour 1

Un autre cadre que j'étudie est Cmockery.

http://code.google.com/p/cmockery/

Il s'agit d'un cadre C pur prenant en charge les tests unitaires et la simulation. Il n'a aucune dépendance sur ruby ​​(contrairement à Cmock) et il a très peu de dépendance sur les bibliothèques externes.

Il faut un peu plus de travail manuel pour configurer les simulations car il ne génère pas de code. Cela ne représente pas beaucoup de travail pour un projet existant car les prototypes ne changeront pas beaucoup: une fois que vous avez vos mocks, vous n'aurez pas besoin de les changer pendant un certain temps (c'est mon cas). La saisie supplémentaire permet un contrôle complet des simulations. S'il y a quelque chose que vous n'aimez pas, vous changez simplement votre maquette.

Pas besoin d'un testeur spécial. Il vous suffit de créer un tableau de tests et de le passer à une fonction run_tests. Un peu plus de travail manuel ici aussi mais j'aime vraiment l'idée d'un cadre autonome autonome.

De plus, il contient quelques astuces C astucieuses que je ne connaissais pas.

Dans l'ensemble, Cmockery a besoin d'un peu plus de compréhension des simulations pour commencer. Des exemples devraient vous aider à surmonter cela. Il semble qu'il puisse faire le travail avec une mécanique plus simple.

En tant que débutant en C, j'ai trouvé les diapositives appelées développement piloté par les tests en C très utiles. Fondamentalement, il utilise la norme assert()avec &&pour délivrer un message, sans aucune dépendance externe. Si quelqu'un est habitué à un framework de test de pile complet, cela ne fera probablement pas l'affaire :)

Nous avons écrit CHEAT (hébergé sur GitHub ) pour une facilité d'utilisation et une portabilité faciles.

Il n'a pas de dépendances et ne nécessite aucune installation ou configuration. Seuls un fichier d'en-tête et un scénario de test sont nécessaires.

#include <cheat.h>

CHEAT_TEST(mathematics_still_work,
    cheat_assert(2 + 2 == 4);
    cheat_assert_not(2 + 2 == 5);
)

Les tests se compilent en un exécutable qui se charge d'exécuter les tests et de rendre compte de leurs résultats.

$ gcc -I . tests.c
$ ./a.out
..
---
2 successful of 2 run
SUCCESS

Il a aussi de jolies couleurs.

Il y a CUnit

Et Embedded Unit est un framework de tests unitaires pour Embedded C System. Sa conception a été copiée à partir de JUnit et CUnit et plus, puis adaptée quelque peu pour Embedded C System. L'unité intégrée ne nécessite pas de bibliothèques C standard. Tous les objets sont alloués à la zone const.

Et Tessy automatise les tests unitaires des logiciels intégrés.

Je n'utilise pas de framework, j'utilise juste le support cible "check" des autotools. Implémentez un "principal" et utilisez des assertions.

Mon répertoire de test Makefile.am (s) ressemble à:

check_PROGRAMS = test_oe_amqp

test_oe_amqp_SOURCES = test_oe_amqp.c
test_oe_amqp_LDADD = -L$(top_builddir)/components/common -loecommon
test_oe_amqp_CFLAGS = -I$(top_srcdir)/components/common -static

TESTS = test_oe_amqp

Le livre de Michael Feather "Working Effectively with Legacy Code" présente de nombreuses techniques spécifiques aux tests unitaires pendant le développement C.

Il existe des techniques liées à l'injection de dépendances spécifiques à C que je n'ai vues nulle part ailleurs.

CppUTest - Cadre hautement recommandé pour les tests unitaires de code C.

Les exemples dans le livre mentionné dans ce thread TDD pour le C intégré sont écrits à l'aide de CppUTest.

J'utilise CxxTest pour un environnement c / c ++ embarqué (principalement C ++).

Je préfère CxxTest car il a un script perl / python pour construire le lanceur de test. Après une petite pente pour le configurer (plus petit encore car vous n'avez pas besoin d'écrire le testeur), il est assez facile à utiliser (comprend des exemples et une documentation utile). Le plus gros travail consistait à configurer le «matériel» auquel le code accède pour que je puisse tester efficacement les unités / modules. Après cela, il est facile d'ajouter de nouveaux cas de tests unitaires.

Comme mentionné précédemment, il s'agit d'un cadre de test unitaire C / C ++. Vous aurez donc besoin d'un compilateur C ++.

Guide de l'utilisateur CxxTest Wiki CxxTest

autre que mon parti pris évident

http://code.google.com/p/seatest/

est un bon moyen simple de tester le code C. imite xUnit

Après avoir lu Minunit, j'ai pensé qu'une meilleure façon était de baser le test en macro assert que j'utilise un peu comme la technique de programme défensif. J'ai donc utilisé la même idée de Minunit mélangée à l'assertion standard. Vous pouvez voir mon framework (un bon nom pourrait être NoMinunit) dans le blog de k0ga

cmockery sur http://code.google.com/p/cmockery/

Google a un excellent cadre de test. https://github.com/google/googletest/blob/master/googletest/docs/primer.md

Et oui, pour autant que je vois, cela fonctionnera avec du C ordinaire, c'est-à-dire qu'il ne nécessite pas de fonctionnalités C ++ (peut nécessiter un compilateur C ++, pas sûr).

Cmockery est un projet récemment lancé qui consiste en une bibliothèque C très simple à utiliser pour écrire des tests unitaires.

Tout d'abord, regardez ici: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C

Mon entreprise possède une bibliothèque C que nos clients utilisent. Nous utilisons CxxTest (une bibliothèque de tests unitaires C ++) pour tester le code. CppUnit fonctionnera également. Si vous êtes coincé en C, je recommanderais RCUNIT (mais CUnit est bon aussi).

Si vous connaissez JUnit, je recommande CppUnit. http://cppunit.sourceforge.net/cppunit-wiki

Cela suppose que vous disposez d'un compilateur c ++ pour effectuer les tests unitaires. sinon, je dois être d'accord avec Adam Rosenfield pour dire que c'est ce que vous voulez.

J'ai utilisé RCUNIT pour faire des tests unitaires pour le code intégré sur PC avant de tester sur la cible. Une bonne abstraction de l'interface matérielle est importante sinon l'endianité et les registres mappés en mémoire vont vous tuer.

essayez lcut! - http://code.google.com/p/lcut

API Sanity Checker - framework de test pour les bibliothèques C / C ++:

Un générateur automatique de tests unitaires de base pour une bibliothèque C / C ++ partagée. Il est capable de générer des données d'entrée raisonnables (dans la plupart des cas, mais malheureusement pas tous) pour les paramètres et de composer des cas de test simples (de «bon sens» ou de «faible profondeur») pour chaque fonction de l'API grâce à l'analyse des déclarations dans l'en-tête des dossiers.

La qualité des tests générés permet de vérifier l'absence d'erreurs critiques dans des cas d'utilisation simples. L'outil est capable de créer et d'exécuter des tests générés et de détecter les plantages (segfaults), les abandons, toutes sortes de signaux émis, le code retour de programme non nul et le blocage de programme.

Exemples:

• Suite de tests pour fontconfig 2.8.0
• Suite de tests pour FreeType 2.4.8

Une technique à utiliser consiste à développer le code de test unitaire avec un framework C ++ xUnit (et un compilateur C ++), tout en conservant la source du système cible sous forme de modules C.

Assurez-vous de compiler régulièrement votre source C sous votre compilateur croisé, automatiquement avec vos tests unitaires si possible.

LibU ( http://koanlogic.com/libu ) a un module de test unitaire qui permet des dépendances explicites de suite / cas de test, l'isolement de test, l'exécution parallèle et un formateur de rapport personnalisable (les formats par défaut sont xml et txt).

La bibliothèque est sous licence BSD et contient de nombreux autres modules utiles - mise en réseau, débogage, structures de données couramment utilisées, configuration, etc. - si vous en avez besoin dans vos projets ...

Je suis surpris que personne ne mentionne Cutter (http://cutter.sourceforge.net/) Vous pouvez tester C et C ++, il s'intègre parfaitement avec les autotools et a un très bon tutoriel disponible.

Dans le cas où vous ciblez des plates-formes Win32 ou le mode noyau NT, vous devriez jeter un œil à cfix .

Si vous êtes toujours à la recherche de frameworks de test, CUnitWin32 en est un pour la plate-forme Win32 / NT.

Cela résout un problème fondamental que j'ai rencontré avec d'autres cadres de test. A savoir les variables globales / statiques sont dans un état déterministe car chaque test est exécuté comme un processus distinct.