Discussion :

[sylvaneau]

Bonjour à tous,

je me permets de poster ici car je ne trouve définitivement pas de réponse à mon problème sur internet.

Je suis en train de développer une application console utilisant la librairie QTestLib dans le but d'effectuer des test unitaires et des test d'interface graphique sur une autre application (jusque là schéma classique, un projet de test séparé du projet principal).

Mon problème réside dans les tests d'interface graphique.
Pour simuler l'appui sur un bouton je passe par la classe QMetaObject, me permettant ainsi d'exploiter les slots exposés par mon interface graphique (QMainWindow), même si ceci sont private.

Le soucis c'est que j'aimerais par exemple accéder aux éléments de l'interface graphique (membre privé "ui" de ma classe QMainWindow) ainsi qu'a d'autres membres privés. Ceci dans le but de tester la validité de ces membres.

Connaissez-vous donc une solution pour acceder aux membres privés d'une classe ? Ou alors etes-vous capable de m'expliquer comment utiliser QTestLib différemment et réaliser des projets de test plus efficaces ?

Je suis parfaitement conscient que tout ceci correspond à violer le principe d'encapsulation, mais dans le cadre de test je pense que c'est "acceptable" (no troll svp ^^).

Merci d'avance pour vos réponses

[johnlamericain]

Différentes idées comme ça, les test d'Interface graphique n'étant pas évidente.

1. Créer des accesseurs publiques sur ta classe permettant d'avoir accès aux éléments graphiques privés. Inconvénient, tous les utilisateurs de ta classe auront accès à ces éléments ce qui est génant si cela t'es utile uniquement pour un test unitaire.
2. Ajouter à ta classe que tu veux tester, la classe de Test Unitaire en tant qu'amis "friend". Ta classe de Test Unitaire sera la seul à avoir accès aux éléments privé de ta classe d'interface graphique. Cela n'est pas très gênant étant donné que c'est la seul fonctionnalité de cette classe.
3. Utiliser les KeyEvent et MouseClick de tes Tests Unitaires sur la fenêtre principale à laquelle tu dois avoir accès (créer dans le main.cpp) et jouer sur le focus de tes widgets pour effectuer les différents tests. Après si tu rajoutes un élément graphique au milieu des autres, cela peut casser tes tests en fonction de comment ça marche...
4. Ajouter un filtre d'événement "event filter", installer uniquement pour tes tests unitaires (projet test unitaire qui défini une variable préprocesseur") qui fait le travail de propagation des événements aux bon widgets, mais ça me parait tirer par les cheveux...

Voilà pour des premières idées

[sylvaneau]

Merci pour ta réponse.

J'avais envisagé les deux premières solutions. La première me dérange un peu car, comme tu l'as dis elle oblige a exposer pas mal de getters juste pour cette tache. Il y a donc la solution de la classe friend (mais là c'est le responsable du développement que çà dérange ^^).

Comme dis dans mon premier post, la classe QMetaObject permet de lister et d'appeler toutes les méthodes d'une classe (qu'elles soient privées ou publiques). Je me demandai s'il n'existait pas un équivalent me permettant de lister les membres privés d'une classe ? (je n'ai rien trouvé). çà ne te dis rien ?

[johnlamericain]

Comme dis dans mon premier post, la classe QMetaObject permet de lister et d'appeler toutes les méthodes d'une classe (qu'elles soient privées ou publiques). Je me demandai s'il n'existait pas un équivalent me permettant de lister les membres privés d'une classe ? (je n'ai rien trouvé). çà ne te dis rien ?

Je ne pense pas, à moins que tu utilises les Q_PROPERTY sur tes membres privés sans fournir d'accesseur/modificateur (get/set) mais je n'ai personnellement jamais essayé.

Quel est le problème d'utilisation d'une classe amie ? Encore un puriste qui ne comprends pas l'utilisation intelligente d'un tel concept ?

[sylvaneau]

Quel est le problème d'utilisation d'une classe amie ? Encore un puriste qui ne comprends pas l'utilisation intelligente d'un tel concept ?

lol ! je ne pense pas ^^ le problème vient plutot du fait que le but est d'éviter d'avoir à recompiler l'application (qui est assez lourde), même si au final çà ne serait à faire qu'une seule fois.
Celà expose aussi quelques problèmes de sécurité (exposition importante de l'application).

L'option n'est pas totalement rejetée, disons que s'il y avait une alternative évitant la recompilation çà serait le must ^^

merci pour tes réponses. si je trouve quelque chose je le posterai.

[johnlamericain]

L'option n'est pas totalement rejetée, disons que s'il y avait une alternative évitant la recompilation çà serait le must ^^

Il y a quelque chose que je ne comprends pas ici.

Un test unitaire est prévu pour détecter qu'il n'y a pas de régression lorsqu'on modifie une classe par exemple. Si tu modifie une classe, c'est normale qu'elle soit recompilée, ensuite tes tests unitaires verifieront que rien n'est cassé. Si elle n'est pas modifié, elle ne sera pas recompilée, donc pas de problème.

Je ne comprends pas ton problème de recompilation... J'ai peut être loupé quelque chose...

Celà expose aussi quelques problèmes de sécurité (exposition importante de l'application)

Un test unitaire est une application locale qui n'est pas fourni avec ton application (en interne à ton entreprise), je ne vois pas le problème de sécurité ?