2009-06-08 7 views
10

J'essaie de lancer un test unitaire. Je regarde quelques frameworks C++ et je veux essayer Boost.Test. La documentation semble très complète, et c'est un peu écrasant, en particulier quelqu'un de nouveau aux tests unitaires. Donc, voici une situation que je veux:Pour commencer à utiliser Boost.Test

Disons que j'ai 2 classes, Foo et Bar. Je veux écrire une suite de tests pour Foo et une suite de tests pour Bar, de préférence dans des fichiers différents. Je ne veux exécuter les tests que si j'exécute le programme avec un paramètre de ligne de commande. Donc, mon main() devrait ressembler à:

int main(int argc, const char* argv[]) 
{ 
    if (argc == 1 && strcmp(argv[0], "-test") == 0) 
     run_all_tests(); 
    else 
     return program_main(argc, argv); 
} 

Je pense que test_foo.cpp devrait être quelque chose comme:

#include "foo.hpp" 
#define BOOST_TEST_MODULE Foo test 
#include <boost/test/unit_test.hpp> 

BOOST_AUTO_TEST_SUITE(Foo_Test) 

BOOST_AUTO_TEST_CASE(Foo1) 
{ 
    Foo f; 
    BOOST_CHECK(f.isValid()); 
} 

BOOST_AUTO_TEST_CASE(Foo2) 
{ 
    Foo f; 
    BOOST_CHECK(f.baz() == 5); 
} 

BOOST_AUTO_TEST_SUITE_END() 

Cependant, je ne sais pas (1) ce que la commande réelle pour exécuter les tests est, et (2) comment dire à la bibliothèque que je veux exécuter TOUT le test.

Alors, qui a de l'expérience avec Boost.Test? Quelqu'un peut-il aider d'une manière détaillée? Merci beaucoup.

Répondre

3

BOOST.Le test est très flexible et vous pouvez probablement faire ce que vous voulez. Toutefois, puisque vous dites que vous êtes novice en matière de tests unitaires, vous devriez probablement suivre la structure de test standard.

Ceci est d'avoir un projet de test distinct pour chaque projet que vous testez. Incluez ensuite les sources et les bibliothèques dont vous avez besoin pour créer le projet de test.

Ceci est plus propre car il n'y a pas de logique de test dans votre projet principal qui pourrait fonctionner accidentellement et il est facile d'exécuter les tests car ils ont leur propre exécutable. Cette approche fonctionne également pour tester les bibliothèques. Si vous suivez cette structure, vous constaterez que la plupart des paramètres par défaut de BOOST.Test fonctionnent correctement et que vous pouvez vous soucier de vous écrire des tests et du code.

0

il n'y a pas coureur de test autonome comme dans NUnit

vous construisez simplement les cas de test comme une seule application .exe (si vous êtes sous Windows) et vous exécutez

+0

Je ne comprends pas ... comment lancez-vous le programme normalement (sans test)? – rlbond

+0

fondamentalement votre test_foo.cpp devrait être construit comme un seul programme .exe et un lien vers votre bibliothèque qui contient des classes Foo & Bar. Un des fichiers d'en-tête boost.test définit déjà la fonction principale, donc je ne pense pas que ce que vous avez proposé soit faisable. – oscarkuo

+1

En fait il y a. C'est ce qu'on appelle console_test_runner. Bien que ce ne soit pas pertinent pour le problème d'OP car il a déjà une main. –

12

Dans votre test_foo.cpp, les macros ajouter suites de tests et cas de test dans à une liste globale: master_testsuite, qui est la racine de tous les nœuds de test . Vous avez juste besoin de compiler tous les fichiers de test comme test_foo.cpp, test_boo.cpp et un coureur, puis les lier tous sur exécutable. La fonction unit_test_main est utilisée pour exécuter les tests au master_testsuite.

boost::unit_test::unit_test_main(
    &init_unit_test, 
    argc, 
    argv 
) 

Sur la base de la macro que vous avez défini avant d'inclure <boost/test/unit_test.h>, Boost.Test peut déjà générer la fonction main pour vous. [1] Le main généré a simplement appelé unit_test_main avec argc et argv dans main. Il est recommandé de utiliser unit_test_main car il peut traiter certains arguments de la console, comme run test by name.

Le premier argument de unit_test_main est un hook. Selon BOOST_TEST_ALTERNATIVE_INIT_API, il a une définition différente. Vous pouvez personnaliser le master_testsuite dans le crochet. Dans le second formulaire , la valeur renvoyée est la nouvelle suite de tests maître.

[1] si BOOST_TEST_MAIN et BOOST_TEST_MAIN sont définis, mais BOOST_TEST_NO_MAIN ne l'est pas.

5

Vous pouvez lancer les tests à partir d'une commande de menu, mais ce n'est pas si simple et malheureusement pas bien documenté. Encore plus triste - il n'est pas possible de passer le chemin où le fichier journal doit être créé. J'ai dû ajouter une telle option de ligne de commande moi-même. Malheureusement, je ne l'ai pas encore soumis. Mon code ressemble à ceci:

#ifdef DEBUG 

#undef main 
#define BOOST_TEST_MAIN 
#include <boost/test/included/unit_test.hpp> 

int DoUnitTests() 

{ 
    char *args[] = {"", "--log_level=all", "--auto_start_dbg=yes"}; 

    bool result = ::boost::unit_test::unit_test_main(&init_unit_test_suite, sizeof(args)/sizeof(char*), args); 

    MessageDlog("Unittests result: %s", result ? "ERRORS in Unittests" : "Goooood!"); 
    return result; 
} 

#else 
int DoUnitTests() 

{ 
} 
#endif 
+0

non, vous ne pouvez pas init 'char * []' avec 'const char * []'. – Abyx

+0

De quoi parlez-vous? S'il vous plaît soyez plus précis. –

+0

Votre code ne sera pas compilé. http://coliru.stacked-crooked.com/a/760be4eb168ba404 – Abyx

0

Essayez ce script que j'ai écrit qui, étant donné un nom de programme et la liste des classes généreront le makefile, squelette de projet et des squelettes suite de tests pour chaque classe/module. Il définit également le tout de sorte que la suite de tests de chaque classe puisse être exécutée individuellement ou dans le cadre d'une suite globale tout-en-un. Il est appelé makeSimple et est disponible sur sourceforge.

Questions connexes