Discussion :

[ymoreau]

Bonjour, je voudrais savoir quelle est la façon la plus simple d'organiser son projet avec des tests unitaires.

J'ai vu que QtCreator permet de créer un projet d'unité de test, sauf qu'avoir un projet par unité me parait bien lourd. D'un autre côté c'est peut être plus pratique pour lancer des tests isolés quand on ne travaille que sur un module ?

J'avoue qu'à la base j'étais plus tenté d'avoir tout dans un seul projet (comprendre .pro), puisque les tests vont utiliser les sources du projet, ça me semblait plus logique. Mais je n'ai jamais essayé d'avoir plusieurs cibles (exécutables) dans un même projet. Et puis toute la partie test devrait être ignorée pour la version release.

Bref si vous avez de l'expérience ou des conseils sur le sujet !
Merci d'avance

Ps : J'ai vu qu'il existait une extension pour manipuler les tests, avec une API simplifiée (et une interface graphique pour lancer les tests) :
https://bitbucket.org/mayastudios/cutetest
Je ne sais pas ce que ça vaut, quelqu'un a déjà utilisé ?

[gbdivers]

Le mieux est d'avoir un .pro dans la racine du projet et des sous répertoires pour les sources, les tests (les 3rnd, la doc, les traductions, etc. tout ce que tu veux) puis faire de la compilation contitionnelle pour inclure les sous dossier ou non

Tu peux regarder comme est organisé le projet QExtend et les .pro correspondant : http://projets.developpez.com/projec...ory/show/trunk

Tu peux mettre par exemple tes tests dans un répertoire spécifique './bin/tests', et puis tu peux utiliser la commande system pour avoir la liste des fichiers, les ajouter comme dépendance avec QMAKE_EXTRA_TARGETS et lancer l'exécution avec PRE_TARGETDEPS (voir le post suivant pour un exemple avec la doc http://www.developpez.net/forums/d11...s/#post6523246)

[ymoreau]

J'ai fait pas mal d'essais (et de bidouilles), avant d'arriver à ceci :
Un fichier .pro global sans TARGET, en TEMPLATE subdirs avec des SUBDIRS pour les exécutables du projet et des tests. Un .pro pour chaque subdir en TEMPLATE app avec dans SOURCES le main. Et enfin .pro qui inclut toutes les classes du projet, sans TARGET ; et qui est inclu par les autres .pro (sauf le global).

Ça ressemble à ça (en simplifié) :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# .pro global
CONFIG   += ordered
TEMPLATE  = subdirs
SUBDIRS   = command1
command1.file = src/command1.pro
debug {
SUBDIRS     += test
test.file    = test/test.pro
}
 
# src.pro
SOURCES += \
    ../src/global/classe.cpp
 
HEADERS += \
    ../src/global/classe.hpp
 
# src/command1.pro
TEMPLATE = app
TARGET   = command1
include(../src.pro)
SOURCES += commands/command1.cpp
 
# test/test.pro
TEMPLATE = app
TARGET   = test
INCLUDEPATH += ../src
include(../src.pro)
SOURCES += test.cpp

Le .pro global et src.pro sont à la racine du projet. Il y a quand même un inconvénient, les chemins de fichiers dans src.pro doivent être valides pour tous les .pro qui l'incluent (et ils sont interprétés dans le répertoire de chacun), j'ai donc dû faire ../src/blabla au lieu de blabla tout court, pour que ça fonctionne aussi depuis le répertoire test. Je ne sais pas si on peut spécifier un dossier d'include pour l'interprétation du .pro ? (cad dire à test.pro d'ajouter les SOURCES et HEADER en partant de ../src plutôt que ./).

Avec ça dans QtCreator je peux directement choisir de lancer l'exécutable de test, ou bien command1, c'est pratique.

[gbdivers]

Le .pro global et src.pro sont à la racine du projet. Il y a quand même un inconvénient, les chemins de fichiers dans src.pro doivent être valides pour tous les .pro qui l'incluent (et ils sont interprétés dans le répertoire de chacun), j'ai donc dû faire ../src/blabla au lieu de blabla tout court, pour que ça fonctionne aussi depuis le répertoire test. Je ne sais pas si on peut spécifier un dossier d'include pour l'interprétation du .pro ? (cad dire à test.pro d'ajouter les SOURCES et HEADER en partant de ../src plutôt que ./).

En général, on ajout un .pri (c'est comme un .pro mais fait pour l'inclusion), que l'on met à la racine du projet et dans lequel on définit les répertoires en se basant sur PWD. Il suffit alors d'inclure simplement ce fichier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
// .pri global
DIR_ROOT = $$PWD
DIR_BIN = $$DIR_ROOT/bin
DIR_SRC = $$DIR_ROOT/src
DIR_INCLUDE = $$DIR_SRC/include
 
// src.pro
include(../global.pri)
SOURCES += $$DIR_SRC/global/classe.cpp
HEADERS += $$DIR_SRC/global/classe.hpp
 
// etc.

On peut également mettre des .pri intermédiaires

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
// src.pri
include(../global.pri)

[ymoreau]

Merci pour l'info, j'ai fait ça, j'en ai profité pour ajouter quelques déclarations propres au projet, mais qui n'étaient en fait pas prises en compte dans les sous-projets en étant déclaré dans le .pro d'ensemble.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
# global.pri et non plus projet.pro donc
QT += core
QT -= gui
CONFIG  += console
CONFIG  -= app_bundle

Il faut juste penser à modifier soi même les chemins dans src.pri car QtCreator quand il ajoute les fichiers se base sur le path relatif (mais bon peut choisir dans quel .pro/.pri les ajouter, c'est déjà pas mal).

J'ai aussi compilé CuteTest pour l'essayer, c'est agréable à utiliser, par contre il n'y a pas d'install par défaut (ou alors j'ai pas trouvé ), donc il faut soit copier à la main les includes et les libs au bon endroit dans le système, soit spécifier des chemins spécifiques à la machine dans le .pro. Mis à part ça l'intégration est très simple, une lib à ajouter, et la variable INCLUDEPATH à mettre à jour.

[gbdivers]

Au fait, tu as testé le module QtTest pour tes tests unitaires ? Ca ne convient pas pour ce que tu veux faire ?
Il doit être possible aussi d'utiliser autotest (pour compiler et suivre tous les résultats des tests) mais j'ai jamais fait

[ymoreau]

En fait CuteTest est une fine surcouche de QTest, l'écriture des classes de tests est légèrement simplifiée avec une macro. Et les tests sont organisés en suite, et tout est appelé automatiquement. Le projet ajoute aussi une interface console ou graphique pour voir les résultats. La lib ne dépend que de Qt donc c'est assez facile à intégrer.

Pour auto-tests j'ai du mal à voir si ça peut être utilisé pour autre chose que tester des patchs pour les sources de Qt. On ne dirait pas.