Quelles options existent pour la création de tests automatisés pour des interfaces graphiques écrites en Java Swing?
J'aimerais tester quelques interfaces graphiques qui ont été créées en utilisant le constructeur d'interfaces graphiques Swing de NetBeans, donc quelque chose qui fonctionne sans nécessiter de manipulation spéciale du code sous test serait idéal.
Je suis actuellement en train d'utiliser FEST. Il fonctionne avec JUnit et prendra également des captures d'écran des tests échoués.
Il dispose de méthodes de recherche de composants par défaut qui cherchent le nom du composant testé (qui doit être défini manuellement), mais vous pouvez également générer les testeurs pour un composant donné en lui passant le composant.
Le Fest swing n'est plus en cours de développement. Il ne prend pas en charge Java 7 non plus. Il semble que la partie swing de Fest soit totalement morte!
Je utilise FEST avec Swing en Java7 juste bien. Voir github.com/bitcoin-solutions/multibit-hd/tree/develop/… pour des scénarios de test complets
Vous pouvez essayer d'utiliser Cucumber et Swinger pour écrire des tests d'acceptation fonctionnels en anglais clair pour les applications GUI Swing. Swinger utilise la bibliothèque Jemmy de Netbeans sous-jacente pour piloter l'application.
Cucumber vous permet d'écrire des tests comme ceci:
Scenario: Manipulation de la boîte de dialogue
Given the frame "SwingSet" is visible
And the frame "SwingSet" is the container
When I click the menu "File/About"
Then I should see the dialog "About Swing!"
Given the dialog "About Swing!" is the container
When I click the button "OK"
Then I should not see the dialog "About Swing!"Jetez un œil à cette démonstration vidéo de Swinger pour le voir en action.
J'utilise java.awt.Robot. Ce n'est pas agréable, ce n'est pas facile mais ça marche à chaque fois.
Avantages :
Inconvénients :
Maintenant, si vous avez le budget, je choisirais LoadRunner. Le meilleur de sa catégorie.
(Divulgation : lien avec l'entreprise qui possède LR, mais j'ai travaillé avec LR avant cette relation)
De mon expérience, je peux dire que le Robot de AWT est extrêmement fragile. Un problème majeur est que son API de bas niveau travaille avec des coordonnées absolues. Les tests peuvent échouer même si votre système sous test (SUT) n'a pas changé (par exemple, lors de l'exécution sur un autre OS).
Je ne l'ai pas utilisé personnellement, mais SwingUnit semble assez bon. Vous pouvez l'utiliser avec jUnit, et il n'est pas basé sur la "position des composants" (c'est-à-dire les coordonnées x et y).
La seule chose que vous pourriez avoir à faire avec le constructeur d'interface graphique de NetBeans est de définir des noms uniques pour vos composants.
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.
2 votes
Question connexe: stackoverflow.com/questions/79891/…
0 votes
Je recommande d'essayer ReTest (retest.de/en), qui met en œuvre une nouvelle approche intéressante des tests de régression fonctionnelle combinés à des tests de monkey basés sur l'IA.