Mon approche des tests GUI évolue, tout comme le consensus de l'industrie. Mais je pense que quelques techniques clés commencent à émerger.
J'utilise une ou plusieurs de ces techniques, en fonction de la situation (par exemple de quel type d'interface graphique il s'agit, à quelle vitesse elle doit être construite, qui sera l'utilisateur final, etc.).
Test manuel. L'interface utilisateur graphique est toujours en cours d'exécution lorsque vous travaillez sur le code et assurez-vous qu'elle est synchronisée avec le code. Vous testez et retestez manuellement la partie sur laquelle vous travaillez pendant que vous travaillez dessus, en basculant entre le code et l'application en cours d'exécution. Chaque fois que vous effectuez un travail important, vous testez l'ensemble de l'écran ou de la zone de l'application pour vous assurer qu'il n'y a pas de régressions.
Tests unitaires.Vous écrivez des tests pour des fonctions ou de petites unités de comportement GUI. Par exemple, vos graphiques peuvent avoir besoin de calculer différentes nuances d'une couleur en fonction d'une couleur «de base». Vous pouvez extraire ce calcul dans une fonction et y écrire un test unitaire. Vous pouvez rechercher une logique comme celle-ci dans l'interface graphique (en particulier la logique réutilisable) et l'extraire en fonctions discrètes, qui peuvent être plus facilement testées à l'unité. Même un comportement complexe peut être extrait et testé de cette manière - par exemple, une séquence d'étapes dans un assistant peut être extraite vers une fonction et un test unitaire peut vérifier que, étant donné une entrée, l'étape correcte est renvoyée.
Explorateur de composants.Vous créez un écran «explorateur» dont le seul rôle est de présenter chacun des composants réutilisables qui composent votre interface graphique. Cet écran vous offre un moyen rapide et facile de vérifier visuellement que chaque composant a le bon aspect et la bonne sensation. L'explorateur de composants est plus efficace que de parcourir manuellement l'ensemble de votre application, car A) vous n'avez à vérifier chaque composant qu'une seule fois, et B) vous n'avez pas à naviguer profondément dans l'application pour voir le composant, vous pouvez simplement afficher et vérifiez-le immédiatement.
Test d'automatisation. Vous écrivez un test qui interagit avec l'écran ou le composant, simulant des clics de souris, la saisie de données, etc., affirmant que l'application fonctionne correctement compte tenu de ces manipulations. Cela peut être utile comme test de sauvegarde supplémentaire, pour capturer les bogues potentiels que vos autres tests pourraient manquer. J'ai tendance à réserver les tests d'automatisation aux parties de l'interface graphique qui sont les plus susceptibles de se casser et / ou qui sont très critiques. Parties où je veux savoir le plus tôt possible si quelque chose s'est cassé. Cela peut inclure des composants interactifs très complexes qui sont vulnérables aux pannes ou aux écrans principaux importants.
Test de Diff / Snapshot. Vous écrivez un test qui capture simplement la sortie sous forme de capture d'écran ou de code HTML et la compare avec la sortie précédente. De cette façon, vous êtes alerté chaque fois que la sortie change. Les tests de différences peuvent être utiles si l'aspect visuel de votre GUI est complexe et / ou sujet à changement, auquel cas vous voulez un retour rapide et visuel sur l'impact d'un changement donné sur l'interface graphique dans son ensemble.
Plutôt que d'utiliser massivement tous les types de tests possibles, je préfère choisir la technique de test en fonction du type de chose sur laquelle je travaille. Dans un cas, je vais donc extraire une fonction simple et la tester unitaire, mais dans un autre cas, j'ajouterai un composant à l'explorateur de composants, etc. Cela dépend de la situation.
Je n'ai pas trouvé que la couverture de code était une métrique très utile, mais d'autres peuvent en avoir trouvé une utilisation.
Je pense que la première mesure est le nombre et la gravité des bogues. Votre première priorité est probablement d'avoir une application qui fonctionne correctement. Si l'application fonctionne correctement, il devrait y avoir peu ou pas de bogues. S'il y a des bogues nombreux ou graves, alors probablement, vous ne testez pas ou vos tests ne sont pas efficaces.
Outre la réduction des bogues, il existe d'autres mesures telles que les performances, la convivialité, l'accessibilité, la maintenabilité, l'extensibilité, etc. Celles-ci varieront en fonction du type d'application que vous créez, de l'entreprise, de l'utilisateur final, etc.
Tout cela est basé sur mon expérience et mes recherches personnelles, ainsi que sur un excellent article sur les tests d'interface utilisateur par Ham Vocke .