Utilisation du package Runit et organisation des tests unitaires pour MTK

1. Création du répertoire trunck/mtk/testsDev/unitTest/

Le fonctionnement de RUnit est différent selon qu'on execute les tests sur un package en mémoire ou sur des fichiers chargés interactivement durant leur développement (actuellement seul le second cas est testé).

 

2. Principe

L'idée de base est la suivante : il s'agit d’exécuter un ensemble de fonctions de tests (nommées selon une convention) et de centraliser le résultat de ces tests dans un document formaté. On a de cette manière une vue synthétique de l'ensemble des résultats des tests.

Pour ce faire il faut respecter 4 étapes :

• créer un objet R « test suite » qui est une collection de fonctions tests et de fichiers relatifs à un sujet (comme une classe par exemple). Cet objet fixe également un certain nombre d'info nécessaires à l’exécution (par exemple la méthode de tirage aléatoire au cas où).

• créer un ou des fichier(s) script R qui contient/contiennent les fonctions exécutant les différents tests.

• exécuter la « test suite » : cet objet va lancer les scripts de fonctions tests

• imprimer le résultat de la série de test dans un doc mis en forme (éventuellement en HTML)

 

3. Choix d'organisation

• On considère comme répertoire racine le rep <root> qui pointe sur

~/<path>/baomexico/trunck/mtk/R

• Les tests unitaires sont dans le répertoire

  <root>/testDev/unitTests

• chaque classe mtk a un répertoire correspondant de test nommé test<mtkClass> (ex : testmtkFactor)

• chaque répertoire de test de classe contient un script R (ex : runmtkFactor.R)

• chacun de ces scripts contient l'ensemble des tests unitaires de méthodes et fonctions propres à la classe

• le résultat de tous les tests est dans le fichier <root>/unitTests/logTests/logUnitTestsMTK.html

 

4. contenu du script R de test unitaire

• .setUp() et .tearDown() sont des fonctions appelées respectivement avant et après l’exécutionUniTests_lisezMoi.odt des tests pour préparer / restaurer l'environnement nécessaire aux tests. Le but étant de veiller à ce qu'aucune variable ou objet de l'environnement R d’exécution provoque un effet de bord.

4. Mode opératoire

• étape 1 : Créer l'objet test suite :

  • Un objet test suite est une liste contenant :

    • un nom

    • un tableau des rep contenant les tests

    • un expression régulière pour identifier les fichiers tests

    • un expression régulière pour identifier les fonctions tests contenues dans ces fichiers

    • les méthodes utilisées pour le tirage aléatoire

  • Nous faisons le choix de créer :(choix à confirmer après usage)

    • une test suite par classe nommé runitmtk<nom_de_la_classe> ex : runitmtkLevel, chaque suite de test correspond à un sous-reprtoire spécifique

    • pour chaque test suite, un fichier composé des fonctions de test des méthodes de la classe

testsuite.mtkLevel <-defineTestSuite(name="mtkLevel", dirs="./testmtkLevel/")

• les test unitaires sont écrits dans le rep ../testDev/test<nom-de-la-classe>

• étape 2 : écrire les fonctions test unitaire

• étape 3 : run des tests :

  • l’exécution se fait en exécutant le script runTEstsScript.R

  • le rapport se trouve dans le répertoire ../mtk/testDev/unitTests/logTests (le nouveau rapport écrase le précédant)

• étape 4 : visualisation des résultats

  • ../mtk/testDev/unitTests/logTests/logUnitTestsMTK.html

 

Ref :

• [1] Ch. Ginolini : construire un package classic et S4 parag 2.2.2

• [2] RUnit König et al, - A Unit test Framework for R sept 2010

 

HR 2011-086-22, Modif du 2012-03-15,  2012-07-09