Comment pouvez-vous écrire des tests pour le sélénium (ou similaire) qui n'échouent pas en raison de changements mineurs ou cosmétiques?

J'ai passé la semaine dernière à apprendre le sélénium et à créer une série de tests Web pour un site Web que nous sommes sur le point de lancer. ça a été super d'apprendre, et j'ai choisi quelques techniques de localisation xpath et css.

le problème pour moi, cependant, est de voir de petits changements casser les tests - tout changement apporté à un div, un id ou un certain nombre autoïde qui aide à identifier les widgets brise tout nombre de tests - il semble juste être très fragile.

avez-vous donc écrit des tests de sélénium (ou d'autres tests similaires), et comment gérez-vous la nature fragile des tests (ou comment les empêchez-vous d'être cassants), et pour quel type de tests utilisez-vous le sélénium?

testing selenium

— Sam J
source

Si de petits changements cassent les tests, alors les tests ne sont pas exécutés une fois les changements effectués - ce qui est tout l'intérêt des tests. De plus, la sensibilisation des développeurs à (l'existence des) tests semble faire défaut.

— talonx

@talonx - il ne suffit pas d'exécuter ce type de test, si un petit changement entraîne un grand changement dans la suite, cela va être problématique, qu'ils soient exécutés par le développeur, la boîte ci ou les testeurs

— FinnNk

@FinnNK: D'accord - de petits changements ne devraient pas entraîner de grands changements. Cela signifie que les cas de test ont été rédigés par une personne qui n'est pas en contact avec les développeurs qui effectuent les modifications - sent comme un manque de communication.

— talonx

@talonx: les tests d'interface utilisateur sont intrinsèquement fragiles et prennent beaucoup plus de temps à exécuter que les tests unitaires. Ils sont un défi particulier, donc je ne tirerais pas de conclusions sur les développeurs de l'organisation de @ Sam.

— azheglov

J'ai changé de titre - j'espère un peu plus représentatif de la question et un peu moins négatif.

— Jon Hopkins

Réponses:

Le but de Selenium est de créer des tests d'intégration pilotés par l'interface utilisateur .

Les tests d'intégration vérifient que tous les composants de votre système fonctionnent correctement lorsqu'ils sont déployés ensemble. Les tests d'intégration ne sont pas une stratégie de test suffisante et complètent d'autres stratégies de test ayant un objectif différent, par exemple les tests unitaires et les tests d'acceptation .

Les tests basés sur l'interface utilisateur sont intrinsèquement fragiles, bien que le sélénium et le watir soient un pas en avant par rapport aux premiers jours des outils d' enregistrement et de lecture . Il existe plusieurs façons de résoudre ce problème - voici une compilation des conseils de certains experts de classe mondiale:

N'essayez pas d'obtenir toute la couverture de vos tests grâce à ce type de tests . Robert C. Martin soutient que votre couverture de code par des tests d'intégration devrait être d'environ 20% . Il est tout simplement impossible de tester tous les chemins d'exécution lorsque l'entrée se trouve à plusieurs couches d'application.

Obtenez la plus grande partie de la couverture des tests grâce aux tests unitaires et d'acceptation . Recherchez les liens vers les articles de Gojko Adzic dans la réponse de FinnNk . Adzic a argumenté à plusieurs reprises sur le test de la logique métier via des tests d'acceptation et le contournement de l'interface utilisateur.

Mais un certain nombre de tests basés sur l'interface utilisateur doivent encore être écrits . C'est là que vous avez besoin de conseils pratiques en plus de "ne testez pas votre logique métier via l'interface utilisateur". Je recommanderais le blog de Patrick Wilson-Welsh comme point de départ.

— azheglov
source

Le lien pour patrickwilsonwelsh.com ne fonctionne plus, et d'autres ressources pour cela .. !!

— MarmiK

La chose la plus importante lors de la création de tests comme celui-ci une fois que vous avez dépassé un nombre trivial est l'idée d'un changement symétrique - un petit changement dans le code devrait entraîner un petit changement dans la suite de tests.

Par exemple, supposons que vous collectiez le nom d'une personne avec deux zones de texte dans 100 tests. Si vous écrivez ces tests niavely (ou utilisez peut-être la lecture d'enregistrement), vous aurez 100 tests à modifier. Si, au lieu de cela, vous résumez une étape de «saisie du nom» et que vous l'utilisez dans vos tests au lieu d'utiliser directement le sélénium, vous n'avez qu'un seul endroit pour effectuer votre modification. Cela dépendra de votre contexte du nombre de couches d'abstraction que vous utilisez - mais l'utilisation de l'abstraction contribuera grandement à rendre vos tests maintenables.

Une deuxième chose importante est de vous assurer que vos sélecteurs sont basés sur la chose la plus importante et la moins susceptible de changer. Parfois, ce sera un identifiant ou une classe ou ce pourrait être le texte dans ou entourant un élément. Préférez toujours le sélecteur le plus simple (par exemple un identifiant) mais parfois pour y parvenir, vous devrez utiliser quelque chose comme xpath.

Gojko Adzic a beaucoup de bons conseils sur son blog en ce qui concerne ce genre de test - consultez son Sine of Death et comment l'éviter en particulier.

— FinnNk
source

bons conseils FinnNk - J'ai résumé les méthodes courantes (connexion, recherche de widgets dans la barre latérale, etc.) - donc les dégâts sont réduits lorsque les tests changent. Malheureusement, nous utilisons un système propriétaire qui crée certains des widgets et crée des identifiants pour les widgets en fonction de leur position dans le dom, donc chaque fois que quelque chose est déplacé, les tests sont rompus.

— Sam J

Habituellement, vous pouvez trouver un moyen d'identifier un élément - peut-être du texte que cet élément contient, ou peut-être qu'il a toujours la même position relative par rapport à autre chose. Enfin, en dernier recours, vous pouvez également définir des stratégies de localisation personnalisées pour localiser des éléments à l'aide de sélénium, ce qui vous donne un contrôle total (par exemple, si vous recherchez des éléments avec le nom de base du nom et des éléments arbitraires ajoutés à la fin, comme dans votre cas ou dans les formulaires Web asp.net).

— FinnNk

Les tests garantissent que le code se comporte comme prévu. Si vos tests échouent régulièrement, alors les tests ne testent pas la bonne chose ou les développeurs ne se soucient pas des tests.

Personnellement, je pense que si la présence d'une <div>balise casse un test, le test dépend inutilement strictement des balises environnantes, et une approche plus clémente devrait être adoptée.