Quelles fonctionnalités doivent être testées via des tests d'interface utilisateur automatisés?

Un consultant nous a récemment dit que si une fonctionnalité ne peut être testée que via des tests d'interface utilisateur automatisés (par exemple Selenium, Coded UI), il y a alors un problème architectural sous-jacent. Bien que cette déclaration puisse être un peu extrême, elle va dans le même sens que la pyramide des tests dans la mesure où les tests d'interface utilisateur devraient constituer une petite partie de votre suite de tests automatisée globale.

Alors, quels types de fonctionnalités devraient avoir des tests d'interface utilisateur automatisés? Un système avec une architecture convaincante aura-t-il toujours des fonctionnalités qui ne peuvent être vérifiées que par des tests d'interface utilisateur, ou ces tests devraient-ils simplement servir de «sauvegarde» pour une suite de tests unitaires et de service?

Vraisemblablement, vous avez une sorte d'architecture qui relie les boutons et autres widgets aux actions - cliquez sur enregistrer et la fonction d'enregistrement devrait être appelée, etc.

En supposant que vous ayez une bonne couverture de test des actions elles-mêmes via des tests unitaires ou d'intégration, l'objectif des tests d'interface utilisateur automatisés est de s'assurer que les widgets appellent tous correctement les actions sous-jacentes et affichent correctement les résultats de ces actions.

En d'autres termes, ils valident que l'interface utilisateur reflète correctement l'état du modèle et est correctement connectée au contrôleur.

L'autre composant est lorsqu'une logique métier se trouve dans le code de l'interface utilisateur. Par exemple, vous avez peut-être besoin de certains caractères dans un champ de mot de passe. Vous devez tester ces fonctionnalités d'une manière ou d'une autre, car il peut être difficile, voire impossible, de le faire via des tests unitaires.

Quelles fonctionnalités doivent être testées via des tests d'interface utilisateur automatisés?

Toutes les fonctionnalités de l'interface utilisateur.

Vous devez tester:

• Toutes les fonctions que les utilisateurs peuvent faire.
• Fonctions que les utilisateurs font dans tous les navigateurs (et versions de) dans lesquels ils les font.
• Les chemins heureux (faire la bonne chose à chaque étape) vs tristes (l'utilisateur fait des erreurs).
• Données valides et invalides.
• Grands et petits nombres.
• Tous les rôles et fonctions rôles spécifiques au rôle.
• Interfaces utilisateur et d'administration.
• Tentatives d'effraction.
• La création et la mise à jour des données fonctionnent comme prévu.
• Supprimer le travail et supprimer les données de base de données associées dans d'autres tables.
• Utilisateurs de style clavier vs souris.
• Différents appareils ou simulateurs de - PC, téléphones, iPad, etc.

Il n'existe pas de fonctionnalité qui ne peut être testée que via des tests d'interface utilisateur automatisés. Des outils comme le sélénium imitent simplement le comportement d'un humain, sans l'ennuyer au point de se suicider. Posez-vous (ou demandez à votre consultant) une question: " Comment un programme testerait-il les aspects de l'interface utilisateur qu'une personne ne peut pas? " La question suivante est: " Si oui, pourquoi vous soucieriez-vous de ce qu'ils font? "

D'un autre côté, si vous avez une telle fonctionnalité, eh bien, je dirais que vous avez un problème architectural sous-jacent. :-)