L'automatisation de la vérification du texte (et de son HTML) peut être un défi si vous n'êtes pas à l'aise avec le langage et le framework que vous utilisez. Avoir un temps limité pour apprendre et explorer constitue un défi en soi. L'une de mes tâches pour automatiser un test de fumée pour notre projet consistait à vérifier le texte dans chaque environnement, chaque configuration spécifique ayant son propre message de bienvenue. Et j’avoue que je ne savais pas trop par où commencer. Je savais ce dont j'avais besoin et j'ai découvert où le récupérer. Mais assembler toutes les pièces n’était pas aussi simple qu’il y paraissait.
J'ai commencé par avoir besoin d'accéder à la base de données. Et puis travaillez avec notre configuration pour vous assurer que je peux utiliser les paramètres de l'application (qui indiquent au framework où trouver les informations et fonctionne avec les paramètres de configuration pour garder les informations privées) pour me connecter à la base de données pendant une exécution. J'ai ensuite pu assembler des éléments, obtenir les informations de la base de données et les comparer avec les informations affichées pour les tests.
Manuellement, c'était simple - j'aurais dû deviner que cela signifiait que cela n'allait pas être aussi facile que je l'espérais. Regarder le HTML et vérifier que les choses étaient dans la bonne mise en page était simple. Je comprends suffisamment la mise en page HTML simple pour qu'il s'agisse d'une vérification rapide pour m'assurer que les mots étaient corrects et continuer. J'avais fait ce test de fumée avec de nombreuses pauses pour vérification manuelle pour une raison. Entre cela et la liste des choses que je devais vérifier, j'allais être encouragé à apprendre, explorer et demander de l'aide pour réussir cette automatisation, et l'appliquer dans les autres tests.
Une fois l'accès à la base de données (et la chaîne de connexion appropriée !) créé, j'ai pu définir le texte des pages comme variable. C’était la partie la plus facile : je savais ce que je faisais ici et je me sentais accompli pour y parvenir. J'ai exécuté le test Playwright, avec un espoir que le texte de la page corresponde au niveau des mots, mais pas aux composants HTML. Et j'avais raison : les mots appropriés étaient là, mais le test a échoué avec l'ajout du code HTML.
Le temps de la recherche ! La première tentative consistait à utiliser Page.ContentAsync(), qui est la commande permettant d'obtenir le code HTML complet de la page, y compris les en-têtes. Cela devrait me permettre de le rechercher et de trouver la sous-chaîne du texte, n'est-ce pas ? Comme première idée, ce n’était pas trop horrible – j’avais enregistré le code HTML que je cherchais, et tout ce que j’avais à faire était de parcourir tout le contenu du document pour le localiser. Pas efficace, et certainement pas une bonne pratique ! Cela devrait me donner le résultat dont j'avais besoin et pourrait ensuite être répété.
Ce n’est pas le cas. Trouver une sous-chaîne dans toute la page n'était pas possible rapidement et je voulais que mon automatisation soit rapide. Après quelques dizaines de tentatives pour que cela fonctionne comme je le souhaitais et en gardant à l'esprit la règle du business (si vous n'arrivez pas à le résoudre en 45 minutes d'effort, il est temps de demander à quelqu'un d'autre), j'ai pris rendez-vous avec l'un des développeurs. Je sais qu'ils sont occupés et créent une mise à jour indispensable : la réunion s'est terminée avec une note « nous pouvons reprogrammer si nécessaire » en pièce jointe.
En attendant la réunion, j'ai continué à m'en préoccuper : l'un des défis pour réduire la zone était la classe du div – il n'était pas bien nommé, et avec Bootstrap, le potentiel de divs en double avec le le même nom m'avait posé des problèmes sur d'autres pages. En parlant à quelqu'un qui était ici depuis bien plus longtemps que moi, j'ai découvert que c'était TOUJOURS la troisième div sur la page.
Maintenant, j'avais un nouveau plan pour le trouver : utilisez le localisateur Nth() et trouvez le div correct. J'aimerais résoudre ce problème, écrire le message que je suis en train de rédiger et passer au prochain problème avant la réunion. Comme beaucoup d’entre vous le savent et/ou le soupçonnent, c’est un bon déclencheur pour que quelque chose d’urgent survienne, et c’est ce qui s’est produit. Les plans ont été copiés de page en page dans l'organisateur pendant plusieurs jours, jusqu'à ce qu'il soit temps pour nous de les développer en binôme.
Travailler avec ce développeur est toujours un régal : nous avons beaucoup de points communs et de respect les uns pour les autres. En prime, ils sont doués pour enseigner ! Après un rapide examen de l'objectif, nous avons passé en revue les tentatives que j'avais faites pour résoudre ce problème. J'avais laissé le dernier, avec les erreurs dans l'IDE, dans l'espoir que cela serait utile. Et maintenant, progressons !
À l'aide du débogueur, nous avons vérifié que le HTML était correctement extrait. C’est un domaine que je n’avais pas complètement vérifié – et heureusement, il était correct. Nous avons convenu que le nom du div n'était pas très utile – le travail qu'ils avaient effectué récemment avait créé un autre div portant ce même nom, mais sur une page différente. Cela a été noté mais déposé jusqu'à ce que j'arrive à ce point du test.
Les compétences en NUnit dont ils disposent étaient nécessaires – le moyen le plus simple de vérifier cette section était d'utiliser la commande AreEqual. Cela a permis au test de vérifier que les chaînes étaient égales. Le dramaturge était têtu. Il souhaitait des localisateurs plutôt que des chaînes – ou l’inverse – dont la création prenait tout simplement trop de temps. Et j’étais heureux d’apprendre cette technique – je vois qu’elle sera utile à l’avenir !
Après quelques tentatives pour faire fonctionner Nth(), nous avons eu recours à cette étrange classe div – après nous être assurés qu’elle n’était utilisée qu’une seule fois sur la page. Cela nous a donné un point de départ – maintenant pour comprendre comment insérer le code HTML (heureusement, c'était la seule chose dans ce div spécifique). Encore quelques faux départs, et j'abandonne finalement l'idée que ContentAsync() pour ce div n'allait pas fonctionner, les conduisent à la solution que j'avais essayée et rejetée.
InnerHtmlAsync() nous a donné le contenu exact du div ! Les espaces et tout. Et c’était la prochaine pierre d’achoppement – et nous n’avions plus de temps pour la réunion. Heureusement, ils étaient prêts à me donner quelques minutes supplémentaires, principalement parce qu’il s’agissait d’un problème qu’ils avaient déjà résolu. J'avais juste besoin de la syntaxe pour supprimer les espaces : Replace(" ", "") si vous étiez curieux. Et cela a permis au test de s'exécuter, jusqu'à ce que le prochain PauseAsync() que j'avais ajouté pour une vérification manuelle l'arrête un instant.
Ils sont partis déjeuner et j'ai passé le temps suivant à préparer des notes. J'avais d'autres choses à trouver – et maintenant je sais plus comment m'y prendre.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!