Code C des tests unitaires [fermé]


854

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.



2
@zmo - Software Recommendations est le site Stack Exchange pour obtenir des recommandations de logiciels. Je ne l'ai pas utilisé, donc je ne peux pas dire à quel point cela fonctionne. Vous devriez vérifier leurs règles de publication avant de publier sur ce site.
Jonathan Leffler

Réponses:


496

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


Au départ, Check a l'air très solide. Je vais devoir voir comment cela résiste sous le feu de l'utilisation réelle ... mais il semble définitivement que cela puisse convenir au projet de loi.
Paul Osborne

8
Nous utilisons la vérification du code de test unitaire sur nos systèmes embarqués. Pour la plupart, check était un bon choix mais maintenant nous travaillons sur des systèmes fonctionnant sur uClinux et comme check nécessite fork, cela ne fonctionne pas sur ces systèmes. : /
David Holm

1
@labyrinth Celui d'Ubuntu date de 2002. La version la plus récente date de cette année (2014 à ce jour). J'ai dû le compiler à partir de la source.
Barry Brown

4
HWUT génère des stubs contrôlables à distance, ce qui est assez pratique si vous souhaitez écrire des tests pour des modules qui interagissent avec des pilotes difficiles. Ces pilotes ne sont, dans la plupart des cas, pas présents sur un PC. Documentation HWUT
Frank-Rene Schäfer

1
Selon la page Github de Check , la dernière version est 0.11.0publiée le 17 décembre 2016 .
Mandeep Sandhu

165

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 .


17
N'achetez pas le prag. livre de prog. Il ne contient aucun aperçu qui ne figure pas dans les réponses à cette question.
Phil

3
Je sais que C et C ++ ont beaucoup de chevauchements, mais cela ne me semble pas une bonne idée d'utiliser une bibliothèque de test C ++ lorsque vous produisez du code qui sera finalement compilé dans un compilateur C.
Rafael Almeida

2
@RafaelAlmeida en substance, je suis d'accord, ce que je montre ici est une couture de préprocesseur sans encapsuler l'inclusion C dans un C. externe. Malgré cela, j'ai trouvé le C ++ très pratique comme langage de description de test dans la pratique. J'ai également écrit un framework basé sur C pour les tests, donc je ne suis pas dogmatique à ce sujet :-) github.com/meekrosoft/fff
mikelong

@Phil je ne suis pas d'accord. J'ai trouvé le livre très précieux, surtout pour quelqu'un qui n'est pas vraiment fort en C.
CHendrix

J'utilise le Fake Function Framework pour se moquer des fonctions HAL, comme indiqué ci-dessus. Cela fonctionne très bien avec gTest. github.com/meekrosoft/fff
Leonardo

135

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


5
Je n'ai aucune expérience dans le domaine des systèmes embarqués, je ne peux donc pas faire de commentaire à ce sujet, mais pour les petits programmes C (travaux scolaires, scripts), cela semble parfait. Excellent lien.
AndrewKS

3
@toasted_flakes J'en ai fait un gistub gistub
Sam

C'est assez proche de ce que j'ai trouvé avant de commencer à chercher ici! Je voudrais automatiser les tests afin que TEST (funcname, body) crée la fonction et stocke un pointeur sur la fonction, mais il semble que j'aurai besoin d'un traitement externe.
Ben Kushigian

41

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 ++.


1
J'appuie le vote pour CuTest. Je l'ai utilisé pour développer des homebrews sur la Nintendo DS et je n'ai eu aucune difficulté à le configurer ou à l'utiliser.
Theran

Je vais en troisième. Je l'ai téléchargé quand c'était la version 1.4 et l'ai modifié pour le vider en XML. Il semble qu'il y ait une version 1.5 que je devrai télécharger et regarder.
Taylor Price

2
CuTest a bien fonctionné pour moi pour tester le code fonctionnant sur un système QNX.
Jace Browning

Il prétend fonctionner comme JUnit, mais il me semble manquer Beforeet Afterappeler. Dans l'ensemble, c'est mignon.
Dragas

40

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).


5
L'unité combinée à la génération de simulation automatisée à l'aide de CMock est assez bonne.
thegreendroid

pouvez-vous suggérer un bon tutoriel pour cmock?
melwin_jose

Il y a un très bon tutoriel pour CMock et Unity, orchestré par Ceedling: dmitryfrank.com/articles/unit_testing_embedded_c_applications
Dmitry Frank

35

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();
}

J'ai roulé à la main mon propre équivalent libtap pour mes propres projets, mais maintenant que je sais que cela existe, je n'aurai plus à maintenir le mien. Cool!
éphémère

1
ok(TESTING==IsSimple(), "libtap is super easy to use")
AShelly

26

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.


3
Quand je regarde cmockery et cmocka, la documentation est similaire. Ces projets sont-ils liés?
Matt Friedman

6
cmocka est le successeur de cmockery. Je l'ai bifurqué car il n'est pas entretenu.
asn

21

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.


8
Vous devriez jeter un oeil à cmocka.org qui est le successeur de cmockery!
asn

pouvez-vous suggérer un bon tutoriel pour cmock?
melwin_jose

Commencez avec l' article LWN , puis vérifiez l'exemple de répertoire de cmocka.
asn

16

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 :)


J'étais tellement gêné par le bug de la fonction is_spare () ... mais merci pour le lien! Je suppose que TDD n'attrape pas TOUS les bogues.
Jis Ben

Il s'agit de l'approche TDD la plus simple que j'ai vue pour C, que vous pouvez suivre assertsans aucune bibliothèque ou infrastructure supplémentaire. Je pense que si vous êtes juste un débutant, cela pourrait être un point de départ.
kabirbaidhya

16

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.


Vote positif pour le joli colo (u) rs
Mawg dit de réintégrer Monica

12

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.


1
J'ai essayé embunitet j'en ai été déçu.
Craig McQueen

1
Par exemple, voir un rapport de bogue que j'ai soumis, ainsi qu'un autre rapport de bogue qui n'a pas été utilisé pendant 3 ans.
Craig McQueen

12

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

2
Nous n'utilisons pas d'auto-outils (bien que ce serait bien de passer à un moment donné). Historiquement, j'ai utilisé la méthode principale à des fins de test et ce n'est pas une mauvaise solution.
Paul Osborne

11

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.



6

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


Le compilateur dont vous avez besoin peut être c ++ mais le code que vous testez peut toujours être C. CxxTest est un framework très facile à utiliser
David Sykes


5

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


J'utilise maintenant votre utest.h dans mon projet. Fonctionne bien et est assez utile. Merci!
Johan



4

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).


Le framework de google fonctionnera-t-il avec du C pur? Un rapide coup d'œil à la page suggère qu'il s'agit d'un framework C ++.
Dana

4
Google Test est excellent, mais c'est vraiment un framework C ++. Il est assez portable et peut être utilisé pour tester C si vous le deviez.
Josh Kelley

4

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


Vous devriez jeter un oeil à cmocka.org qui est le successeur de Cmockery.
asn


2

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.


6
La question concerne C, pas C ++
1800 INFORMATION

3
Non, mais C ++ peut s'interfacer avec les bibliothèques C. Il peut donc être en fait parfaitement correct de tester les bibliothèques C à l'aide d'un framework de test unitaire C ++. (Mon entreprise le fait d'ailleurs et c'est tellement plus facile que d'utiliser des frameworks de test unitaire C.)
Kevin

Je fais la même chose. Nous avons une bibliothèque d'utilitaires écrite en C que nous utilisons sous notre code C ++ et nos langages de script. Nous utilisons CppUnit pour les tests et cela fonctionne plutôt bien puisque nous pouvons utiliser le même framework pour C et C ++.
Jyaan

2

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.


2

3
Une documentation serait utile. Le contexte et les objectifs du projet, une liste de fonctionnalités, les avantages par rapport aux alternatives existantes, etc. seraient utiles pour les personnes qui le vérifient pour la première fois.
Craig McQueen

2

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:


1

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.


1

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 ...




0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.