1. Introduction1.1- Définition

- Cunit est un système permettant d’administrer, d’écrire et d’exécuter les tests unitaires de programmes écrits en C.

- Il utilise une plateforme permettant de construire des structures de test et fournissant un ensemble d’affirmations (assertion) riche pour le test des types de données communes.

- Il offre différentes interfaces, statiques et dynamiques, pour lancer les tests et reporter les résultats.

#include <CUnit/CUnit.h> Macros d’affirmations pour les cas de test et inclus les en-têtes de la plate-forme

#include <CUnit/CUError.h> Déclaration des fonctions de prise en main des erreurs et la définition des types de

données

#include <CUnit/TestDB.h> Fonctions de manipulation des registres, des suites et des tests

#include <CUnit/TestRun.h> Fonctions d’exécution des tests et de récupération des résultats

#include<CUnit/Automated.h> Interface automatique avec résultats au format xml

#include <CUnit/Basic.h> Interface basique non interactive avec sortie au format stdout

1.2- Cet outil offre les fichiers d’en-tête suivants

1. Introduction1.3- Structure générale du test

Registre du test

Suite ‘1’ Suite ‘2’ Suite ‘N’…

Test ‘11’ Test ‘1M’ Test ‘11’ Test ‘1M’……Les cas de test individuels sont regroupés dans des suites qui sont enregistrées avec le

registre de test actif. Les suites peuvent contenir des fonctions d’initialisation et d’arrêts qui sont automatiquement appelées avant et après le lancement d’une suite de

tests. Il existe des des fonctions permettant de lancer d’une manière exhaustive ou sélective les tests et suites d’un registre actif.

1.4- Utilisation générale1. Écriture des fonctions pour les tests et les suites (intialisation et désallocation) si nécessaire

2. Initialisation du registre de test - CU_initialize_registry()

3. Ajout des suites de test au registre - CU_add_suite()

4. Ajout des tests aux suites - CU_add_test()

5. Lancer le test en choisissant l’interface adéquoite, e.g. CU_console_run_tests

6. Effacer le registre de test - CU cleanup registry

2. Implémentation d’un test2.1- Fonction test

void <Nom_fonc_test>(void)

Il n’y a aucune restriction sur le contenu de la fonction test, sauf qu’elle ne doit pas modifier les paramètres de la plate-forme CUnit. Par exemple, elle ne doit pas ajouter des test, modifier le registre de test ou initialiser un test. Elle peut appeler d’autres fonctions.

Exemple

Soit la fonction maxi qui retourne le max de deux entier :int maxi(int i1, int i2) {

return (i1 > i2) ? i1 : i2; }

void test_maxi(void){CU_ASSERT(maxi(0,2) == 2);CU_ASSERT(maxi(0,-2) == 0);CU_ASSERT(maxi(2,2) == 2);}

La fonction assurant le test de maxi est :

2. Implémentation d’un test2.2- Les Affirmations (Assertions)

- Cunit fournit un ensemble d’assertions assurant le test des conditions logiques. Le succès ou non de ces assertions sont récupérés par la plate-forme et affichés à la fin de l’ exécution du test.

- Chaque assertion teste une condition logique unique. Si cette évaluation est FALSE, l’assertion est dite fautive ou non réussie.

- Lorsqu’une faute est activée, la fonction test continue l’ exécution de son scénario de test sauf si l’utilisateur choisisse la version fatale de l’assertion. Dans ce cas, la fonction test est arrêtées sans faire appel à une éventuelle fonction de dés allocation. Remarque :-Il existe des assertions spéciales permettant de récupérer un résultat de succès ou non sans l’évaluation d’un test logique. Ceci est très utile pour le test des flots de contrôles.- les assertions sont définies dans : #include <CUnit/CUnit.h>

void test_longjmp(void) {jmp_buf buf; int i; i = setjmp(buf);if (i == 0) {run_other_func();CU_PASS("run_other_func() succeeded.");} elseCU_FAIL("run_other_func() issued longjmp.");

}

Exemple :

3. Registres, suites et tests

CU_ErrorCode CU_initialize_registry(void)Initialisation et libération des registres

void CU_cleanup_registry(void)

CUE_SUCCESSCUE_NOMEMORY

CU_pTestRegistry CU_get_registry(void), Set, create_new, destroy_existingUtilisation des registres

#include <CUnit/TestDB.h>3.1- Gestion des registres

3.2- Gestion des suites

3.3- Gestion des tests

CU_pSuite CU_add_suite(const char* strName,CU_InitializeFunc pInit,CU_CleanupFunc pClean)

Ajout de suites

Retour en cas d’echec

CUE_SUCCESS, CUE_NOREGISTRY,CUE_NO_SUITENAME, CUE_DUP_SUITE, CUE_NOMEMORY

Ajout de testsCU_pTest CU_add_test(CU_pSuite pSuite, const char* strName, CU_TestFunc pTestFunc)

Création de raccourcis#define CU_ADD_TEST(suite, test) (CU_add_test(suite, #test,

(CU_TestFunc)test))

4. Lancement des tests et gestion des erreurs

4.1- Lancement des tests

a- Différents modes de lancement

b- Récupération des résultatsLes interfaces présentent le résultats des tests. Cependant, le code du testeur pourrait avoir besoin de résultats intermédiaires. Ces résultats peuvent inclure le nombre de lancements. Voir <CUnit/TestRun.h> pour plus de détails.

Non interactif :- CU_ErrorCode CU_basic_run_tests(void)- CU_ErrorCode CU_basic_run_suite(CU_pSuite pSuite)Interctif : - void CU_curses_run_tests(void)

CUnit peut lancer aussi bien le test des toutes les suites enregistrées, ainsi que des tests ou suites spécifiques. Durant l’exécution du test, la plate-forme enregistre le nombre des suites, des tests et des assertions en exécution, réussis ou non.RemarqueLes résultats sont effacés à chaque nouveau lancement.

unsigned int CU_get_number_of_suites_failed(void)const CU_pRunSummary CU_get_run_summary(void)

Il existe deux modes possibles pour le lancement des test: non interactif et interactif.

4.2- Gestion des erreurs

a- Récupération des erreurs

b- Réaction aux erreurs

Cunit est un logiciel, il présente ainsi plusieurs erreurs permettant de repérer son comportement. Par exemple, erreur d’initialisation de registre, duplication du nom d’une suite de test, erreur d’ouverture de fichier, etc. Voir CUnit/CUError.h pour la liste exhaustive.

CU_ErrorCode CU_get_error(void)const char* CU_get_error_msg(void)

void CU_set_error_action(CU_ErrorAction action)CU_ErrorAction CU_get_error_action(void)

Par défaut, si une erreur plate-forme survient, son code est enregistré et le scénario de test est poursuivit. Parfois, le testeur a besoin d’arrêter le test afin d’éviter la corrélation des fautes. (ignorer, le test arrêté ou l’application exité )

4. Lancement des tests et gestion des erreurs