Comment puis-je tester par unité une interface graphique?

Question

Les calculs dans mon code sont bien testés, mais comme il y a beaucoup de code d'interface graphique, la couverture globale de mon code est inférieure à celle que je souhaiterais. Existe-t-il des directives sur le code d'interface graphique de tests unitaires? Cela a-t-il même un sens?

Par exemple, mon application contient des graphiques. Je n'ai pas été capable de comprendre comment automatiser le test des graphiques. Il faut un œil humain, autant que je sache, pour vérifier si le graphique est correct.

(J'utilise Java Swing)

Answer 1

Les conceptions telles que MVP et MVC essaient généralement d’abstraire autant de logique que possible de l’interface graphique réelle. Un article très populaire à ce sujet est "La boîte de dialogue humble" de Michael Feathers. Personnellement, j'ai eu plusieurs expériences en essayant de sortir la logique de l'interface logique: parfois, cela fonctionnait très bien et d'autres fois, cela posait plus de problèmes que cela ne valait la peine. Cela relève cependant un peu de mon domaine de compétence.

Answer 2

Bien sûr, la solution consiste à utiliser MVC et à déplacer autant de logique que possible hors de l'interface graphique.

Cela étant dit, un collègue de travail m'a dit il y a longtemps que, lorsque SGI portait OpenGL sur un nouveau matériel, il disposait d'un ensemble de tests unitaires permettant de tracer un jeu de primitives à l'écran, puis de calculer la somme MD5 du frame buffer. Cette valeur peut ensuite être comparée aux bonnes valeurs de hachage connues pour déterminer rapidement si l’API est précise par pixel.

Answer 3

Vous pouvez essayer UISpec4J est une bibliothèque de tests fonctionnels et / ou de tests unitaires Open Source pour applications Java basées sur Swing. ...

Answer 4

Voici quelques conseils:

Essayez de supprimer le plus de code possible de l'interface graphique (avec le contrôleur et l'objet modèle). Ainsi, vous pourrez les tester sans l'interface graphique.

Pour le graphique, vous devez tester la valeur que vous fournissez au code qui génère le graphique.

Answer 5

Vous pouvez essayer d'utiliser Concombre et Swinger pour la rédaction de tests d'acceptation fonctionnels en anglais simple pour les applications d'interface graphique Swing. Swinger utilise la bibliothèque Jemmy de Netbeans sous le capot pour piloter l'application.

Le concombre vous permet d’écrire des tests comme celui-ci:

 Scenario: Dialog manipulation
    Given the frame "SwingSet" is visible
    When I click the menu "File/About"
    Then I should see the dialog "About Swing!"
    When I click the button "OK"
    Then I should not see the dialog "About Swing!"

Jetez un coup d'œil à cette démonstration vidéo Swinger pour la voir. en action.

Answer 6

Il existe Selenium RC , qui automatise le test de l'interface utilisateur Web. Il va enregistrer des actions et les rejouer. Vous devrez tout de même parcourir les interactions avec votre interface utilisateur. Cela n’aide en rien la couverture, mais il peut être utilisé pour les versions automatisées.

Answer 7

Le test est une forme d'art. Je suis d'accord que la logique devrait être supprimée autant que possible GUI. Nous pouvons alors concentrer nos tests unitaires là-bas. Comme toute autre chose, les tests visent à réduire les risques. Vous n'avez pas toujours besoin de tout tester, mais souvent, la meilleure chose à faire est de diviser les différents tests dans différents domaines.

L’autre question est de savoir ce que vous essayez réellement de tester au niveau de l’interface utilisateur. Les tests d'interface utilisateur sont les tests les plus coûteux, car leur création, leur maintenance et leur durée sont généralement plus longues. Si vous testez la logique pour savoir si les coordonnées sont correctes avant d'essayer de tracer la ligne, que testez-vous spécifiquement? Si vous souhaitez tester un graphique avec une ligne rouge est dessiné. Pouvez-vous lui donner un ensemble de coordonnées prédéterminées et tester si certains pixels sont rouges ou non rouges? Comme suggéré ci-dessus, les comparaisons bitmap fonctionnent, mais je m'attache surtout à ne pas sur-tester l'interface graphique, mais plutôt à tester la logique permettant de créer l'interface utilisateur, puis de se concentrer sur la partie suspecte de l'interface utilisateur et sur la focalisation de quelques tests. là-bas.

Answer 8

Vous pouvez utiliser JFCUnit pour tester votre interface graphique, mais les graphiques peuvent être plus complexes. À quelques reprises, j'ai pris des instantanés de mon interface graphique et l'ai automatiquement comparée à une version précédente. Bien que cela ne fournisse pas un test réel, il vous avertit si une génération automatique ne produit pas le résultat attendu.

Answer 9

Ce que je comprends de votre question est que vous cherchez une méthode automatisée pour tester votre comportement en interface graphique en détail. L’exemple que vous donnez est de vérifier si une courbe est dessinée correctement.

Les frameworks de tests unitaires permettent d'effectuer des tests automatisés, mais je pense que les types de tests que vous souhaitez effectuer sont des tests d'intégration compliqués qui vérifient le comportement correct d'une multitude de classes, parmi lesquelles les classes de votre boîte à outils / bibliothèque d'interface graphique. , que vous ne devriez pas vouloir tester.

Vos options dépendent beaucoup des plates-formes / outils / frameworks que vous utilisez: par exemple, une application utilisant Qt en tant que framework d'interface graphique peut utiliser Squish pour automatiser ses tests. Vous vérifiez les résultats de vos tests une fois, puis les tests exécutés automatiquement comparent les résultats aux résultats vérifiés.

Answer 10

Licker de fenêtre pour Swing & amp; Ajax

Answer 11

De ce que je sais, ceci est assez compliqué et dépend vraiment de la langue - de nombreuses langues ont leur propre façon de tester l'interface graphique, mais si vous avez vraiment besoin de tester l'interface graphique (par opposition à l'interaction modèle / interface graphique), vous doivent souvent simuler un utilisateur réel en cliquant sur les boutons. Par exemple, la structure SWT utilisée dans Eclipse fournit SWTBot , JFCUnit a déjà été mentionné, Mozilla a sa propre façon de simuler cela dans XUL (et d'après ce que j'ai lu sur leurs blogs, ces derniers les tests semblent assez fragiles).

Vous devez parfois prendre une capture d'écran et tester le rendu au pixel près (je pense que Mozilla le fait pour vérifier si les pages sont correctement rendues). Cela nécessite une configuration plus longue, mais peut-être ce dont vous avez besoin pour les graphiques. Ainsi, lorsque vous mettez à jour votre code et qu'un test s'interrompt, vous devez vérifier manuellement l'image si l'échec est réel, ou vous avez amélioré le code de rendu des graphes pour générer de plus jolis graphiques et mettre à jour les captures d'écran.

Answer 12

Si vous utilisez Swing, le FEST-Swing est utile pour piloter votre interface graphique. et tester des assertions. Il est assez simple de tester des choses comme "si je clique sur le bouton A, la boîte de dialogue B doit être affichée" "ou " si je sélectionne l'option 2 dans le menu déroulant, toutes les cases à cocher doit être désélectionné ".

Le scénario graphique que vous avez mentionné n’est pas si facile à tester. Il est assez facile d'obtenir une couverture de code pour les composants d'interface graphique simplement en les créant et en les affichant (et éventuellement en les pilotant avec FEST). Cependant, faire des assertions significatives est la partie difficile (et la couverture de code sans assertions significatives est un exercice d'auto-illusion). Comment testez-vous que le graphique n'a pas été dessiné à l'envers ou trop petit?

Je pense que vous devez simplement accepter le fait que certains aspects des interfaces graphiques ne peuvent pas être testés efficacement par des tests unitaires automatisés et que vous devrez les tester autrement.

Answer 13

Ce n'est pas à vous de tester la bibliothèque d'interface graphique. Vous pouvez donc éviter la responsabilité de vérifier ce qui est réellement dessiné à l'écran et de vérifier plutôt les propriétés des widgets, en faisant en sorte que la bibliothèque leur indique avec exactitude ce qui est dessiné.