Utiliser cppUnit pour gérer ses tests unitaires

Cette classe est la classe principale du framework. Virtuelle pure, elle définit entre autres la fonction runTest, fonction qui est naturellement appelée lors de l'exécution des tests. C'est elle qui sera surchargée par nos tests unitaires. Les autres fonctions membres servent à diverses tâches telles que le comptage du nombre de tests, récupérer les résultats des tests à travers le pattern Visitor…

Classe la plus élémentaire, elle est dérivée de Test au travers de TestLeaf. Elle peut être considérée comme une feuille de l'arbre des tests.

Cette classe implémente le pattern Composite, à savoir une arborescence dans les tests. C'est le moyen de hiérarchiser facilement et efficacement ses tests.

Cette classe est virtuelle, mais a deux filles.

Dans certains cas, les tests envisagés nécessitent de mettre en place un cadre, charger des données, mais aussi de « nettoyer » après les tests. Deux fonctions supplémentaires sont à surcharger pour accomplir cette dernière tâche dans la classe TestSetUp.

Certains tests doivent être répétés plusieurs fois, ce que la classe RepeatedTest permet d'accomplir.

Parfois, on ne veut pas dériver une multitude de classes pour des tests différents. En effet, pour tester une bibliothèque matricielle par exemple, créer une classe par type d'opération peut être démesuré, tout comme mettre tous les tests dans une seule classe. La classe TestFixture permet de répondre à cette question.

Pour lancer les tests, une autre classe est utilisée. Chaque classe de test est enregistrée dans TestRunner à l'aide de la méthode addTest, et on lance la totalité des tests à l'aide de la méthode run.

Un petit

./configure && make && make install

permet d'installer facilement la bibliothèque. Si vous voulez l'installer sans être root ou dans un dossier particulier, faites plutôt un

./configure --prefix=/dossier/local/dinstallation/ && make && make install

Avec un autre environnement de développement, plusieurs solutions sont envisageables. Si on décide de compiler avec Visual Studio, tout est déjà disponible. Dans le cas contraire, il faudra reconstruire un projet.

II-B-1. Compilation avec MSVC▲

II-B-2. Compilation avec un autre IDE▲

Nous allons commencer par lancer l'interface graphique. Afin de simplifier la compilation, nous utiliserons les fichiers .pro à utiliser avec qmake – il faut ajouter plusieurs définitions du préprocesseur pour que l'application se lance avec une compilation standard sous Visual Studio –. L'interface doit donc ressembler à quelque chose de ce genre

On va donc créer un fichier .pro. Tout d'abord la configuration

CONFIG        += debug qt warn_on

Donc on compile en mode debug, avec qt et avec les warnings.

SOURCES = main.cpp

On va simplement utiliser un seul fichier source, main.cpp

TARGET          = cppunit-example
DEPENDPATH      = .
OBJECTS_DIR     = objs
MOC_DIR         = mocs

La cible à créer est un exécutable s'appelant cppunit-example, on stocke les fichiers objets dans le sous-dossier objs, les fichiers résultant d'un moc dans le dossier mocs tandis que la liste des dossiers utilisés pour les dépendances est limitée au dossier courant.

INCLUDEPATH     = c:/travail/cppunit-1.10.2/include

Ici, indiquez le dossier dans lequel se trouvent les en-têtes de cppUnit, dans mon cas, c'est c:/travail/cppunit-1.10.2/include.

LIBS += c:\travail\cppunit-1.10.2\lib\cppunitd_dll.lib c:\travail\cppunit-1.10.2\lib\qttestrunner.lib

Ici, mettez vos librairies .lib, avec Visual Studio, il s'agit du chemin d'accès complet tandis que pour les GCC, on indiquera par -Lchemin le chemin d'accès et -llibrarie chaque librairie, donc -lcppunit et -lqttestrunner.

Maintenant, le fichier main.cpp :

#include <QtGui/QApplication>
#include <cppunit/ui/qt/TestRunner.h>

D'abord, on va inclure les en-têtes indispensables, donc QApplication pour pouvoir créer une application avec Qt et TestRunner.h qui va définir l'interface graphique elle-même.

int main(int argc, char* argv[])
{
    // Create the QtTestRunner:
    QApplication app(argc, argv);
    CppUnit::QtTestRunner runner; 

    // Run the GUI:
    runner.run();
  
  return 0;
}

Le corps de la fonction main elle-même est simple, on crée la QApplication, l'interface graphique TestRunner puis on lance les tests.

Comme précisé dans la première partie, les tests dérivent de la classe Test. En particulier, on va utiliser la classe TestCase et surcharger virtuellement sa fonction runTest().

HEADERS = test.h

On va donc juste définir une petite classe dans le fichier test.h, classe qui sera entièrement inlinée pour simplifier.

#include <cppunit/extensions/HelperMacros.h>

On va ajouter un en-tête dans notre nouveau fichier test.h, celui qui définit des macros pour simplifier l'écriture des tests.

class PseudoTest : public CppUnit::TestCase
{ 
public:
  PseudoTest( std::string name ) : CppUnit::TestCase( name ) {}
  
  void runTest()
  {
    CPPUNIT_ASSERT( 1 == 1 );
    CPPUNIT_ASSERT( !(1 == 2) );
  }
};

Notre classe va donc s'appeler PseudoTest, surtout parce que c'est un exemple, pas une vraie classe. Le constructeur va passer à son père, TestCase, le paramètre name qui est le nom du test. La fonction de test elle-même, runTest, utilise la macro CPPUNIT_ASSERT. En paramètre, une simple condition à tester, comme pour la fonction assert classique.

#include "test.h"

    runner.addTest(new PseudoTest("test de base"));

On indique simplement à l'instance de la classe TestRunner qu'on veut ajouter un test qui sera une instance de la classe PseudoTest qu'on a déclarée avant. Le résultat est maintenant clairement visible.

On va maintenant essayer d'aller un peu plus loin en utilisant une autre classe dérivant de Test, TestFixture. Cette classe propose simplement de gérer plusieurs fonctions de test. De plus, nous allons utiliser un singleton fourni par la bibliothèque pour enregistrer tous nos tests automatiquement au démarrage de l'application. Il ne sera donc plus utile de les ajouter avec la méthode addTest().

SOURCES        = main.cpp test.cpp

On ajoute un fichier source à la compilation.

#include "test.h"

CPPUNIT_TEST_SUITE_REGISTRATION( PseudoTest );

Le fichier est simple, outre l'inclusion du fichier d'en-tête, on a une nouvelle macro, CPPUNIT_TEST_SUITE_REGISTRATION, qui indique simplement qu'on enregistre au démarrage une suite de test au démarrage.

class PseudoTest : public CppUnit::TestFixture
{ 
public:
  CPPUNIT_TEST_SUITE( PseudoTest );
  CPPUNIT_TEST( testsReussis );
  CPPUNIT_TEST( testsRates );
  CPPUNIT_TEST_SUITE_END();

  /// Méthode dont les tests réussissent
  void testsReussis()
  {
    CPPUNIT_ASSERT( 1 == 1 );
    CPPUNIT_ASSERT( !(1 == 2) );
  }
  
  /// Méthode dont les tests ratent
  void testsRates()
  {
    CPPUNIT_ASSERT( !(1 == 1) );
    CPPUNIT_ASSERT( 1 == 2 );
  }
};

On décide donc de dériver PseudoTest de TestCase et de créer deux fonctions, testResussis et testsRates, la deuxième fonction ne contenant que des tests qui ratent. Ensuite, trois macros sont utilisées, CPPUNIT_TEST_SUITE, CPPUNIT_TEST, CPPUNIT_TEST_SUITE_END, qui vont permettre de commencer l'inclusion des différentes fonctions à la suite de test, inclure les fonctions que l'on veut et de finir la série d'inclusion.

#include <cppunit/extensions/TestFactoryRegistry.h>

        CppUnit::TestFactoryRegistry &registry = CppUnit::TestFactoryRegistry::getRegistry();
        runner.addTest( registry.makeTest() );

TestFactoryResgistry est le singleton qui contient les tests enregistrés par la macro CPPUNIT_TEST_SUITE_REGISTRATION. On peut ajouter d'autres tests tout de même à l'aide d'addTest. Le résultat est le suivant

Les tests enregistrés au démarrage avec le singleton sont répertoriés avec leur arborescence - voir avec le bouton Browser - sous l'intitulé « All Tests ».

L'avantage indéniable, c'est qu'on a accès à tout, on peut tout faire. Des arborescences de test, des environnements, tester des plug-ins… Toutes ces capacités ont été testées et le design utilisé est propre, simple et efficace.

Les inconvénients, c'est plus difficile à trouver. On peut reprocher l'absence d'interface graphique « native », mais le plus gros point est que la mise en place et l'enregistrement des tests sont complexes, en même temps, on ne peut pas avoir le beurre et l'argent du beurre.