Les calculs dans mon code sont bien testés, mais parce qu'il y a beaucoup de code GUI, la couverture globale de mon code est plus faible que je ne le voudrais. Existe-t-il des directives sur le test unitaire du code GUI ? Cela a-t-il même un sens ?
Par exemple, il y a des graphiques dans mon application. Je n'ai pas réussi à trouver comment automatiser le test des graphiques. Il faut un œil humain, AFAIK, pour vérifier si le graphique est correct.
(J'utilise Java Swing)
Les conceptions telles que MVP et MVC tentent généralement d'abstraire autant de logique que possible de l'interface graphique réelle. Un article très populaire à ce sujet est "L'humble boîte de dialogue" par Michael Feathers. Personnellement, j'ai eu des expériences mitigées en essayant de déplacer la logique hors de l'interface utilisateur - parfois, cela a très bien fonctionné, et d'autres fois, cela a été plus de problèmes que cela n'en valait la peine. Mais c'est un peu en dehors de mon domaine d'expertise.
? ?? "Parfois, cela a très bien fonctionné, et à d'autres moments, cela a causé plus d'ennuis que cela n'en valait la peine. Très bizarre parce que la plupart des nouveaux langages ont tendance à être orientés MVC... ce qui signifie que la logique sort du gui (Modèle-Visuel)...
Pourtant, la logique de présentation sera dans l'interface graphique. Parfois, cela peut être loin d'être trivial.
Bien sûr, la réponse est d'utiliser MVC et de déplacer autant de logique que possible hors de l'interface graphique.
Ceci étant dit, un collègue m'a dit il y a longtemps que lorsque SGI a porté OpenGL sur un nouveau matériel, ils avaient un tas de tests unitaires qui dessinaient un ensemble de primitives à l'écran puis calculaient une somme MD5 du frame buffer. Cette valeur pouvait ensuite être comparée à de bonnes valeurs de hachage connues pour déterminer rapidement si l'API est précise par pixel.
J'aime cette approche. Elle est lourde à mettre en place et à maintenir, mais elle me donnerait les capacités de test de régression dont j'ai besoin.
Danatel vous n'avez pas compris. OpenGL est une API de rendu graphique précise au pixel près. Les frameworks d'application GUI comme Qt vont être très dépendants du système chromatique, donc hacher le frame buffer n'est pas une bonne approche.
Vous pouvez essayer UISpec4J est une bibliothèque Open Source de tests fonctionnels et/ou unitaires pour les applications Java basées sur Swing...
J'ai commencé à utiliser UISpec4J depuis un mois environ pour effectuer des tests de validation des exigences sur les interfaces graphiques Java Swing. Jusqu'à présent, je l'ai beaucoup apprécié.
github.com/UISpec4J/UISpec4J indique que votre lien est le site officiel, mais il ne me semble pas si officiel que ça. Tout ce que je vois, c'est un blog sur le vlogging.
Vous pouvez essayer d'utiliser Concombre y Échangiste pour l'écriture de tests d'acceptation fonctionnelle en anglais simple pour les applications Swing GUI. Swinger utilise la bibliothèque Jemmy de Netbeans pour piloter l'application.
Cucumber vous permet d'écrire des tests comme ceci :
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 à ceci Démonstration vidéo de l'échangisme pour le voir en action.
Voici quelques conseils :
Essayez de retirer le plus de code possible de l'interface graphique (ayez un contrôleur et un objet modèle), de cette façon 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.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Martin Fowler a rédigé un excellent article sur les différentes architectures d'interface graphique ( martinfowler.com/eaaDev/uiArchs.html ). Il décrit les compromis de l'architecture GUI en termes de tests unitaires.
1 votes
De nos jours, il serait préférable de poser cette question sur programmeurs.stackexchange.com (et est probablement hors sujet sur Stack Overflow, au motif qu'il est trop large), mais les anciennes questions ne peuvent pas être migrées. La question de savoir si elle a sa place ici mise à part, le problème reste intéressant et difficile.
1 votes
Ce serait bien d'avoir un exemple avec un morceau de code GUI et JUnit.
2 votes
Je vous dirais de vous détendre et de ne pas vous donner la peine. L'effort fourni pour les tests unitaires ne s'avère pas toujours productif.
0 votes
Vieille question toujours, vous pouvez tester le flux dans l'interface graphique en utilisant Jubula.