La classe robot, selon moi, c'est overkill pour du unit test. Ca va simuler des clic et des entrées souris via le système natif de l'OS. Autrement dit, si ça clic à coté, tu peux balancer tout ton test au final dans un email, effacer des fichiers dans l'exploreur, etc. Assez dangereux et de toutes façons très difficile d'avoir un feedback pour le tapper dans un Assert.
Personellement, quand je dois tester que des composants swings se comportent correctement, c'est souvent des tests de synchro. Genre "a tiens, si je sélectionne tel élement dans la liste, tel et tel JTextField doivent s'activer". Et ça c'est assez facile à tester. Tu instancie la JFrame, tu crée un getter pour avoir la JList et les textfields, et ton test deviens
1 2 3
| Fenetre maFenetre = new Fenetre();
maFenetre.getLaListe().setSelectedIndex(3);
assetEquals("Tartempion",maFenetre.getNameField().getText()); |
Pour des chose un peu plus complexe, genre "HA si je clique droit sur le JLabel, une JPopup dois apparaitre", c'est plus complexe. Tu peux facilement balancer l'event via processMouseEvent() sur le composant. Pour détecter l'affichage de la JPopup, tu pourrais utiliser powerMockito pour intercepter les new sur JPopupMenu et en conclure que, oui, on a bien lancer une popup. Ou diviser mieux ton code pour que la popup soit gérée par une classe à part facilement mockable.
Pour le reste, les interactions complexe, rien ne vaut l'oeil du testeur au final.
Partager