Tests unitaires
Les test unitaires sont le seul moyen d'assurer une rétro compatibilité. Quand un logiciel évolue, il doit
pouvoir passer les tests que les versions précédentes ont passées. Quand un bug est trouvé et résolu,
ce qui l'a mis en évidence doit être rajouté à la liste de tests unitaires. Dans le principe, c'est très simple,
on ne teste qu'en mode DEBUG, et on encadre les tests par un "if debug". En principe (et c'est une bonne chose),
les test unitaires doivent être écrits avant la fonction à tester.
Ce que l'on doit tester
Les tests unitaires ne testent que le logiciel, pas les fonctions utilisant le hardware!
Testons par exemple une fonction qui additionne deux mots de 16 bits non signés
et qui retourne la somme en un mot de 16 bits non signé.
"datatypes.h" pour micro 8 bits
"datatypes.h" pour micro 32 bits
Le fichier "datatypes.h" contient la définition des types de données, différents en fonction des micros.
Une pratique courante consiste à y mettre tout ce qui peut être un déclaration globale,
comme la définition de __DEBUG__ pour les compilateurs qui ne la connaissent pas.
Le type int par exemple fait 16 bits sur un micro 8 bits, 32 sur un micro 32 bits...
Première chose, tester les "effets de bord", pour que la fonction soit portable d'un micro à un autre.
Une seule fonction de test
Pour tester un module, il faut lui inclure le fichier "assert.h", présent dans la plupart des compilateurs.
Ce fichier contient une macro qui s'appelle assert, et que l'on utilise comme une fonction.
L'affirmation à tester doit être différente de zéro.
Affirmations vraies:
Affirmations fausses arrêtant le programe et générant un message d'erreur:
Un exemple complet
"mainprog.c" : module programme principal
"dummy.h" : module à tester
"dummy.c" : module à tester
"datatypes.h" (sur PC 32 bits): module à tester
"comp.bat" : commande de compilation
Pierre Faller Home Page - Since 1999