Avant de pouvoir être mis en production les programmes doivent être testés afin d'établir leur fiabilité et leur tolérance aux fautes.
On recommande aux programmeurs de mettre en place des tests qui ont pour but de débusquer les bogues inhérants à chaque programme.
En Génie Logiciel notamment une bonne pratique de développement est le Développement Dirigé par les Tests (Test Driven Development) qui consiste à développer les programmes de tests avant d'écrire les classes de l'application.
Il existe différents types de tests, on peut citer par exemple :
Pour réaliser les tests unitaires on peut utiliser le framework xUnit notamment le CppUnit. Pour cela il faut installer les librairies libcppunit-1.13-0 et libcppunit-dev.
Voir également le site web cppunit
Voici un exemple de base qui introduit des méthodes de test pour la classe vector de la STL :
Par défaut, les méthodes setUp et tearDown permettent d'allouer + initialiser et de libérer les ressources. Dans le cas présent je crée un vector<int> que je remplis avec 100 entiers de 1 à 100.
A l'intérieur de chaque méthode de test on utilise la macro instruction CPPUNIT_ASSERT qui permet de vérifier si une condition est validée ou non.
On compile avec les options suivantes :
g++ -o test_vector_1.exe test_vector_1.cpp -lcppunit
Puis on exécute en lançant le programme, voici le résultat de la sortie en mode texte :
./test_vector_1.exe
==============================================
TEST vector (test_vector_1.cpp)
==============================================
....F.F
test_vector_1.cpp:89:Assertion
Test name: test_fail1
assertion failed
- Expression: 0 == 1
test_vector_1.cpp:96:Assertion
Test name: test_fail2
assertion failed
- Expression: true == false
Failures !!!
Run: 5 Failure total: 2 Failures: 2 Errors: 0
Le programme reporte les assertions non vérifiées CPPUNIT_ASSERT(0 == 1); de la ligne 89 du programme et CPPUNIT_ASSERT(true == false); de la ligne 96.
Voici la sortie au format XML :
On peut ensuite extraire les méthodes qui ont échoué grâce à un utilitaire comme xpath du package libxml-xpath-perl :
sudo apt-get install libxml-xpath-perl
> xpath -q -e "//FailedTest/Name/text()" output.xml
test_fail1
test_fail2
Voici un script shell qui permet de récupérer les noms des méthodes qui ont échoué tout en vérifiant que tous les tests ont été exécutés :
> ./cppunit_failures_1.sh
===================
test_vector_1.exe
- test_fail1
- test_fail2
===================
Voici une version avancée qui prend en compte le nombre de tests et qui permet de vérifier que l'ensemble des tests à été exécuté.
En effet, si l'une methode échoue et provoque par exemple un segmentation fault, les autres méthodes ne seront pas exécutées et il ne sera pas possible de le savoir. On risque donc de penser que tout va bien alors que certains tests n'ont pas été exécutés.
> ./cppunit_failures_1.sh
===================
test_vector_1.exe
- test_fail1
- test_fail2
===================
Récupérer googletest-release-1.7.0.tar.gz sur googletest, puis dans le répertoire où le fichier a été télécharger taper :
sudo tar -xvzf googletest-release-1.7.0.tar.gz -C /opt
sudo su
cd /opt/googletest-release-1.7.0
cmake -DBUILD_SHARED_LIBS=ON -Dgtest_build_samples=ON -G "Unix Makefiles"
make
cp -R include/gtest /usr/include
cp lib*.a /usr/lib
ldconfig
exit
Créer le fichier suivant :
et compiler avec :
g++ -o my_gtest.exe my_gtest.cpp -lgtest -lgtest_main -lpthread