Quels tests automatiser dans une application web full stack? API vs UI

Question

J'ai récemment rejoint une équipe d'automatisation de pile complète. Il existe des tests de sélénium pour le frontend et les API ne sont pas encore automatisées. Ma question ou ma réflexion est la suivante: devrais-je choisir les cas de test avec soin pour éviter tout chevauchement entre le sélénium frontal et le backend. Reste assuré des tests basés sur? Ou il est courant d'avoir des cas de test qui se chevauchent dans ce scénario.

Les API backend ne sont consommées que par le Web, il n'y a pas d'équipes mobiles ou autres qui les utilisent.

Answer 1

Vous devez toujours choisir les tests avec soin en ce qui concerne l'automatisation des tests. :)

L'une des raisons, comme vous l'avez dit, est le chevauchement (et avec cela, le temps d'exécution et la robustesse). Un exemple pour clarifier:

• Votre API a 10 points de terminaison qui peuvent renvoyer chacun plusieurs messages d'erreur différents.
• Ne testez pas chaque erreur comme un test d'interface utilisateur: cela prendra beaucoup de temps d'exécution et entraînera également la maintenance la plus élevée. Et oui, vous aurez un chevauchement fonctionnel avec l'API et les tests unitaires.
• Ne testez pas chaque erreur en tant que test API si leur logique est entièrement couverte dans les tests unitaires.
• N'écrire un test de l' interface utilisateur pour une ou deux erreurs pour vous assurer qu'ils sont correctement affichés par la fin de l' avant. Mais il s'agit probablement d'un système générique, donc si le système fonctionne, il fonctionnera pour tout message d'erreur. Les tests d'interface utilisateur doivent être considérés comme sondant les flux de l'application et voir qu'un utilisateur peut faire le travail, et non comme des tests approfondis de la logique.
• Faites des tests API écrire pour une ou deux erreurs pour vous assurer que l'intégration back-end joue bien de la demande à la réponse (au - delà de la portée des tests unitaires). Ou écrivez plus de tests pour des cas spécifiques (par exemple lorsque l'accès à la base de données entre en jeu, qui sera simulé dans un test unitaire).

Une autre raison de réfléchir aux cas à automatiser est simplement que tous les tests automatisés ne sont pas aussi utiles ou rentables à long terme. Je vous conseille de regarder sur YouTube la présentation d'Angie Jones sur "Quels tests faut-il automatiser" - voir aussihttps://slides.com/angiejones/which-tests-should-we-automate#/20

Answer 2

Il n'y a pas de concept de chevauchement des cas de test dans différents niveaux de test,

Les deux sont complètement isolés

Juste parce que l'API fonctionne correctement, vous ne pouvez pas garantir que l'interface utilisateur fonctionne correctement.

Imaginez que tous vos tests d'API réussissent mais que l'utilisateur ne puisse pas utiliser l'interface utilisateur, imaginez que toute votre interface utilisateur fonctionne en raison des informations mises en cache mais que le backend réel échoue.

Assurez une couverture de plus bas niveau comme le test unitaire et le test API, cela garantit une exécution de test plus rapide et des commentaires de construction. Cela garantira également un débogage plus rapide car vos tests seront plus axés sur le composant ou la fonctionnalité.

Dans le test de l'interface utilisateur, le flux commercial réel et les tests de gestion des erreurs

Dans chaque niveau de test, nous avons différentes portées de test.

Test de l'unité;

Nous ne testons pas le flux commercial mais le composant et la fonctionnalité

Test d'intégration

Intégration avec d'autres composants, quelle est la stabilité du sous-système intégré pour pouvoir être utilisé pour s'étendre avec des composants de niveau supérieur. Comme l'API avec l'interface utilisateur

Test du système

Ici, vous testez la convivialité, les interactions des utilisateurs, la régression visuelle, la logique métier et le flux.

Il n'y a donc pas de concept de chevauchement des tests dans différents niveaux de test

Answer 3

TL; DR : vous aurez un chevauchement entre les cas de test d'intégration E2E et API, en ce qui concerne les mêmes points de terminaison exercés dans les deux et c'est OK - cela vous aide à déterminer où est le problème si (... quand) quelque chose ne va pas.

Lorsque vous travaillez avec une base de code qui ne dispose actuellement pas de tests automatisés complets, commencez par les tests E2E (/ fonctionnel / UI) . Pourquoi?

1. L'automatisation de l'application via les flux de travail de l'interface utilisateur permet de créer de l'empathie pour les utilisateurs - à quoi servent-ils et comment le font-ils?

2. Ces tests vous permettent de vérifier que le logiciel fournit réellement la valeur qu'il est censé offrir; vos utilisateurs ne se soucient pas des appels ou des fonctions d'API! Notez que ce serait différent si votre API était un produit en soi, et pas seulement consommé par le client Web.

3. Dans une perspective de test plus technique, les tests de niveau inférieur nécessiteront probablement des changements à mettre en œuvre (par exemple, pour introduire des limites appropriées pour tester); le code écrit sans penser aux tests est souvent difficile à tester. Vous avez besoin des tests de niveau supérieur pour vous assurer que ces modifications ont été effectuées correctement.

Cela conduira probablement à un endroit où vous aurez trop de tests E2E, caractérisés par des durées de test trop longues, mais vous pouvez maintenant commencer à pousser les tests vers le bas de la pile vers l'intégration et les tests unitaires. Mettre l' accent sur le maintien d' un ensemble de flux de travail clés (cela peut être une bonne conversation avec les gens de ce produit dans votre équipe - que tout le monde sait ce que les flux de travail clés sont ?) Au niveau E2E, puis poussez les chemins moins importants et la répétition à niveau inférieur des tests.

En ce qui concerne les tests API en particulier, il y aura beaucoup de chevauchement; vos cas de test E2E doivent tester chaque point de terminaison au moins une fois (sinon, demandez-vous si les points de terminaison inutilisés peuvent être supprimés). Ce chevauchement est correct, car maintenant, si un test E2E échoue mais que les tests API pertinents réussissent, vous avez localisé le problème dans l'interface utilisateur. Mais il y aura des choses difficiles à tester via l'interface utilisateur. Ce sont généralement les chemins malheureux , par exemple:

• vous avez probablement une validation des entrées au niveau de l'interface utilisateur qui empêche la demande d'être effectuée si elles sont invalides, mais vous devriez toujours tester la validation côté serveur; et

• vous n'avez probablement pas de liens vers des ressources manquantes dans l'interface utilisateur, mais vous souhaitez tout de même tester les 404.

De même, il y a des choses difficiles à tester via l'API et qui nécessitent beaucoup de configuration et de démontage; dans ce cas, poussez plus loin pour tester unitaire la couche de logique de service / métier (je ne recommanderais pas de tester unitaire les couches contrôleur / transport ou référentiel / persistance; celles-ci ont tendance à être largement passe-partout, si elles ont beaucoup de logique, c'est probablement dans au mauvais endroit).

Answer 4

Il n'est pas nécessaire de tester la même chose avec les tests API et UI.

Commencez par l'API (en gardant à l'esprit la pyramide des tests ), à condition que le code soit suffisamment couvert par des tests unitaires, et automatisez certains scénarios e2e qui couvriraient les cas non couverts par l'API individuelle.

Answer 5

Mon instinct est de me concentrer d'abord sur l'automatisation de l'API backend.

• Les tests unitaires sont bons et nécessaires, mais ils ne me donnent pas une grande confiance dans le fonctionnement du système dans son ensemble. Certains des bogues les plus insidieux se produisent lorsque différentes parties de la spécification interagissent d'une manière à laquelle l'auteur n'a pas pensé, et les tests unitaires ont tendance à capturer uniquement une vue très "locale" de la spécification.
  Disons que dans une classe les valeurs nulles sont rejetées comme non valides, dans une autre classe les valeurs nulles sont interprétées comme une liste vide. Les chances sont que les tests unitaires pour chaque classe testent fidèlement exactement ce comportement.

• Les tests GUI sont bons et nécessaires, mais ils sont également difficiles s'ils sont censés remplacer les tests manuels. Il y a tellement d'appareils différents, tellement de navigateurs différents. Un test automatisé qui vous indique que le système est «bon à utiliser» sur de nombreux appareils représente beaucoup de travail. (Cela pourrait être un léger biais de ma part à cause de mon arrière-plan backend, et cela suppose que la logique métier est dans le backend ...).

• Les tests API représentent le «contrat» d'un sous-système par rapport à un autre. Il peut être difficile de générer des données de test à la fois réalistes et exhaustives, mais une fois que vous les avez, vous pouvez être certain que le backend fait ce qu'il est censé faire.