tester - Test d'unité C Code




title tester (20)

Après avoir lu Minunit, je pensais que le meilleur moyen était de baser le test sur la macro d'assertion que j'utilise beaucoup comme technique de programme défensive. 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) sur le blog de k0ga

J'ai travaillé sur un système embarqué cet été écrit en C. C'était un projet existant pour lequel l'entreprise pour laquelle je travaille avait pris le relais. Je suis devenu assez habitué à écrire des tests unitaires en Java en utilisant JUnit mais je ne savais pas comment écrire des tests unitaires pour du code existant (qui nécessitait un refactoring) ainsi que du nouveau code ajouté au système.

Existe-t-il un moyen de rendre le test C unitaire aussi simple qu'un test de code Java avec, par exemple, JUnit ? Toute idée qui s'appliquerait spécifiquement au développement intégré (compilation croisée avec la plate-forme arm-linux) serait grandement appréciée.


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

Mon entreprise a 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é dans C, je recommanderais RCUNIT (mais CUnit est bon aussi).


En tant que débutant C, j'ai trouvé les diapositives intitulées Test driven development en C très utile. Fondamentalement, il utilise la norme assert() avec && pour livrer un message, sans aucune dépendance externe. Si quelqu'un est habitué à un framework de test de pile complet, cela ne fonctionnera probablement pas :)



Il y a CUnit

Et l' unité embarquée est la structure de test unitaire pour le système C intégré. Son design a été copié à partir de JUnit et CUnit et plus, et ensuite adapté un peu pour Embedded C System. L'unité embarquée ne nécessite pas de librairies C std. Tous les objets sont alloués à la zone const.

Et Tessy automatise les tests unitaires des logiciels embarqués.


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


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 aussi bien que sur le bureau. En plus d'écrire les tests unitaires, tout ce qui est requis est:

  • un fichier d'en-tête inclus partout où vous appelez les routines CuTest
  • un seul fichier 'C' supplémentaire à compiler / lier dans l'image
  • du code simple ajouté à main pour configurer et appeler les tests unitaires - je l'ai juste dans une fonction spéciale main () 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 (ce qui n'est pas le cas de tous les systèmes embarqués). Mais le code est assez simple que vous pourriez probablement travailler dans des alternatives à ces exigences si votre plate-forme ne les a pas.

Avec une utilisation judicieuse des blocs externes "C" {}, il supporte aussi le test C ++.


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

Unity - Cadre hautement recommandé pour le test unitaire du code C.

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


Je n'utilise pas de framework, j'utilise simplement autotools "check" support de la cible. Mettre en place un "principal" et utiliser assert (s).

Mon test 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

Je suis surpris que personne n'a mentionné Cutter (http://cutter.sourceforge.net/) Vous pouvez tester C et C ++, il s'intègre parfaitement avec autotools et a un tutoriel vraiment sympa disponible.


LibU ( http://koanlogic.com/libu ) dispose d'un module de test unitaire qui permet des dépendances de suites de tests / cas explicites, une isolation de test, une 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 courantes, configuration, etc. - si vous en avez besoin dans vos projets ...


Nous avons écrit CHEAT (hébergé sur GitHub ) pour faciliter l'utilisation et la portabilité.

Il n'a aucune dépendance et ne nécessite aucune installation ou configuration. Seul un fichier d'en-tête et un cas 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 sont compilés dans un exécutable qui s'occupe de faire les tests et de rapporter leurs résultats.

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

Il a de jolies couleurs aussi.


Si vous êtes toujours à la recherche de frameworks de test, CUnitWin32 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é en tant que processus séparé.


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

C'est en supposant que vous avez compilateur c ++ pour faire les tests unitaires. sinon, je suis d'accord avec Adam Rosenfield que le chèque est ce que vous voulez.


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

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


Vous pouvez aussi jeter un coup d'œil à libtap , un framework de test en C qui produit le protocole TAP (Test Anything Protocol) et qui s'intègre ainsi parfaitement à une variété d'outils issus de cette technologie. Il est principalement utilisé dans le monde de la langue dynamique, 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();
}



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

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 mais malheureusement pas toutes) pour les paramètres et de composer des cas de test simples ("sains" ou "peu profonds") pour chaque fonction de l'API via l'analyse des déclarations 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 générer et d'exécuter des tests générés et de détecter les pannes, les interruptions, toutes sortes de signaux émis, le code de retour du programme différent de zéro et la suspension du programme.

Exemples:


CppUTest - CppUTest hautement recommandé pour le test unitaire du code C.

Les exemples dans le livre qui est mentionné dans ce fil TDD pour C intégré sont écrits en utilisant CppUTest.





embedded