Introduction aux tests automatisés de bout en bout

Transcription de la vidéo

Nous avons utilisé ChatGPT pour améliorer la grammaire et la syntaxe de la transcription.

Bonjour à tous. Je suis heureux que vous soyez tous là et j'espère que vous avez pris de la caféine. Si nous n'avons pas encore eu l'occasion de nous rencontrer, je m'appelle Paul. J'ai travaillé à l'Université du Missouri pendant une vingtaine d'années, où j'étais chargé de mettre en place et de maintenir les processus et les flux de travail pour la gestion de leurs parcs de sites WordPress. J'ai donc une longue expérience de l'enseignement supérieur et de WordPress. Je suis maintenant ingénieur chargé des relations avec les développeurs chez Platform.sh. Si vous ne nous connaissez pas, nous sommes un fournisseur de plateforme en tant que service sécurisé et de qualité professionnelle. Nous éliminons les complexités de la gestion de l'infrastructure cloud afin que vous et vos équipes puissiez passer plus de temps à répondre aux besoins changeants de votre institution et à soutenir vos missions institutionnelles, et moins de temps à lutter contre l'infrastructure cloud. Que ce soit sur site ou à distance, qu'il s'agisse de WordPress, de Drupal, de Django, de Gatsby ou de tout autre logiciel dont vous avez besoin, vous pouvez gérer tout cela à partir d'un point central. Nous pouvons jouer un rôle crucial dans vos tests de bout en bout.

Avant de commencer, je tiens à vous mettre en garde. Tout d'abord, je ne suis pas un expert en matière de tests. Cette présentation, comme la plupart de mes présentations, a vu le jour parce qu'on m'a confié une tâche. On m'a demandé d'ajouter des tests de bout en bout à certaines des choses que nous soutenons. Je n'y connaissais pas grand-chose et j'ai donc dû apprendre. Au cours de ce processus, j'ai pensé que d'autres pourraient peut-être en tirer profit. J'ai demandé au canal WordPress si quelqu'un était intéressé, et j'ai reçu une excellente réponse. C'est ainsi que cette présentation a vu le jour.

Deuxièmement, je vais faire tout cela en direct aujourd'hui, et vous savez comment se déroulent les démonstrations en direct, alors souhaitez-moi bonne chance. Je vais probablement occuper les 45 minutes.

Mes objectifs pour vous lorsque vous quitterez cette salle aujourd'hui sont les suivants :

Je veux que vous puissiez définir ce qu'est un test de bout en bout.
Je veux que vous puissiez vous souvenir d'au moins un avantage que les tests de bout en bout apportent à vos flux de travail ainsi qu'à votre organisation.
Je veux que vous compreniez ce qu'est Cypress, comment l'installer, comment le configurer et comment écrire au moins votre premier test.
Je veux que vous connaissiez les stratégies et les meilleures pratiques et que vous ayez toutes les connaissances de base dont vous avez besoin pour construire les deuxième, troisième et quatrième tests.
Alors, combien d'entre vous font déjà des tests automatisés sous une forme ou une autre dans leurs flux de travail ? Merveilleux. Combien d'entre vous effectuent des tests de bout en bout ? Quelques-uns ? Bon, alors pour tous les autres, si on vous confiait une tâche ou si vous deviez écrire une nouvelle caractéristique ou une nouvelle fonctionnalité, comment feriez-vous pour vérifier que ce que vous avez écrit fonctionne comme vous l'attendez ?

[Réponse d'un membre de l'auditoire] "Visiter le site".

Exactement, vous visitez le site et vous le faites manuellement, n'est-ce pas ? Eh bien, c'est tout ce qu'est un test automatisé. Les tests de bout en bout imitent l'utilisateur réel et tentent de reproduire les étapes qu'il suivrait, puis vérifient que l'application a fait exactement ce que nous attendions d'elle. Les tests de bout en bout ne sont rien d'autre que l'automatisation de ce processus manuel.

Cela présente des avantages considérables. Dans de nombreux cas, nous ne pouvons pas mettre en évidence les problèmes de notre logiciel tant qu'il ne fonctionne pas dans un scénario réel où il interagit avec la base de données, dispose d'une interface utilisateur et se connecte à tous ces services tiers. Nous ne pouvons pas vraiment mettre en évidence ces problèmes tant que nous ne l'avons pas testé comme le ferait l'utilisateur. Mais cela prend du temps, et c'est là que les avantages de l'automatisation entrent en jeu. En outre, comme nous pouvons détecter ces bogues avant qu'ils ne se produisent - avant de les mettre en production -, il est beaucoup moins coûteux de les corriger. Une fois que nos tests sont réussis, nous avons la certitude que ce que nous introduisons ou déployons en production fonctionnera exactement comme prévu et n'affectera pas négativement l'expérience de l'utilisateur, ce qui accroît notre assurance qualité. Enfin, si vous travaillez avec des départements qui vous donnent un ensemble de fonctionnalités qu'ils souhaitent, et que vous pouvez écrire votre test pour vérifier ces fonctionnalités, vous pouvez alors vous assurer que vous êtes en phase avec les exigences de l'entreprise.

En quoi les tests de bout en bout diffèrent-ils des autres types de tests ? Si vous connaissez la pyramide des stratégies de tests automatisés, nous effectuons des tests unitaires au bas de l'échelle. Nous en faisons un grand nombre, mais ils sont isolés et ne testent que des éléments individuels. Ensuite, nous passons aux tests intégrés, où nous commençons à tester notre code avec des services externes. Nous en faisons moins car ils sont un peu plus difficiles à réaliser. Au sommet, nous effectuons des tests de bout en bout, c'est-à-dire que nous testons tout. Mais comme nous testons tout, c'est beaucoup plus complexe, nous en faisons moins, l'objectif étant que ces tests manuels soient très rares.

Maintenant, si vous n'êtes pas familier avec les deux autres, les tests unitaires sont l'idée que dans un monde idéal - et je sais que l'enseignement supérieur n'est pas idéal - mais dans un monde idéal, vous écrivez un test pour tester le plus petit morceau de fonctionnalité que vous pouvez. Ensuite, vous écrivez le test avant d'écrire la fonctionnalité. Dans votre langage de programmation, il s'agit généralement d'une fonction ou d'une méthode. Lorsque vous écrivez cette fonction ou cette méthode, vous la testez continuellement, encore et encore, mais vous l'isolez de toutes ses requêtes externes afin de ne tester que cette fonctionnalité. C'est la raison pour laquelle nous le faisons très souvent, car cela nous permet d'obtenir un retour d'information immédiat. Une fois que nous commençons à obtenir des résultats positifs - nous réussissons tous ces tests unitaires -, nous passons aux tests intégrés. Nous pouvons prendre les unités individuelles que nous avons testées, les regrouper et commencer à les tester en tant que groupe. Nous pouvons prendre notre code et commencer à le tester avec des dépendances ou des services externes dans le but de mettre en évidence tout problème de communication entre notre code et ces dépendances externes. Nous revenons ensuite aux tests de bout en bout, où nous imitons tout du début à la fin et essayons de vérifier, exactement comme le ferait un utilisateur, que nos fonctionnalités fonctionnent.

Cela dit, si nous devons le faire beaucoup moins souvent, c'est parce que c'est plus coûteux. Cela peut être à la fois monétaire, parce que nous allons devoir mettre en place un environnement ou un serveur pour exécuter ces tests, mais aussi en termes de ressources humaines - il faut du temps pour rédiger tous ces tests. De temps en temps, je parlerai de fragilité. Il peut aussi être un peu difficile à maintenir. Par exemple, disons que vous écrivez une fonctionnalité qui ajoute un élément de menu à la barre d'administration. Ensuite, l'utilisateur doit aller quelque part, il doit avoir un panneau, remplir quelques informations et faire quelque chose. Nous pouvons écrire le test, vérifier que tout fonctionne correctement, et puis dans l'itération suivante, quelqu'un décide de changer l'ID de cet élément de menu. Tout à coup, nous ne pouvons plus accéder à cet élément de menu dans notre test, comme nous le faisions auparavant, et le test est interrompu, même si la fonctionnalité est toujours présente. Voilà donc un exemple de test fragile. Nous devons être conscients qu'ils peuvent être un peu fragiles.

Donc, Cypress. Combien d'entre vous ont entendu parler de Cypress ? Quelqu'un a joué avec ? Quelques-uns ? Ok, pour tous les autres, Cypress est un framework de tests automatisés open-source dont l'objectif principal, lorsqu'il a été conçu ou commencé à être construit, était d'accélérer le temps entre le moment où vous l'installez et celui où, en tant que développeur, vous commencez à écrire vos tests. Auparavant - l'âge des ténèbres, je suppose - il y avait beaucoup de configuration et d'installation impliquées dans la construction de l'automatisation du navigateur. L'objectif était encore une fois de vous permettre d'entrer dans le système et d'écrire ces tests aussi vite que possible.

Aujourd'hui, il présente certains avantages spécifiques. C'est un logiciel libre ; ils ont un produit SaaS optionnel. Il n'utilise pas Selenium, il n'utilise pas WebDrivers ; il utilise une application Electron et il embarque votre application - votre application web - à l'intérieur de cet Electron, ce qui signifie que tout fonctionne à l'intérieur du navigateur, donc c'est très, très rapide. Aujourd'hui, tous les navigateurs sont pris en charge, à l'exception de Safari, qui est sur la feuille de route. L'autre élément intéressant est le voyage dans le temps et la relecture des tests. Ainsi, lorsque vous exécutez un test, vous pouvez revenir en arrière, rejouer le test et observer l'évolution de l'état de votre application au fur et à mesure qu'elle franchit les différentes étapes. Le voyage dans le temps vous permet ensuite de revenir à une étape individuelle et de voir l'état de votre application, ses performances, et d'observer exactement ce qui se passe à chaque étape lorsque vous avancez ou reculez. En outre, tout ce que vous envoyez à la console sera disponible dans cette étape, et vous disposez de toute une série d'outils de débogage qui vous permettent de déboguer votre test et de découvrir exactement pourquoi il échoue.

D'autres éléments intéressants sont l'attente automatique. Ainsi, lorsque vous visitez un site, il suivra automatiquement les redirections jusqu'à ce qu'il arrive à une page 200. Puis, une fois la page obtenue, il attendra que l'événement de chargement de cette page se déclenche avant de continuer. Si vous demandez un élément DOM, comme dans une application dynamique, il attendra automatiquement jusqu'à ce que cet élément DOM soit disponible ou jusqu'à ce qu'il soit épuisé. L'attente automatique est donc une fonctionnalité intéressante qui vous permet de vous assurer que les choses se sont chargées comme vous le souhaitiez.

Le contrôle du trafic réseau est également très intéressant. Vous pouvez intercepter n'importe quelle requête - donc n'importe quelle requête vers un point d'extrémité ou un emplacement - vous pouvez l'intercepter, l'inspecter, modifier les données qu'elle envoie, et lorsque la charge utile est renvoyée, vous pouvez l'attraper et manipuler ces données, ou vous pouvez l'attraper et renvoyer vos propres données, sans jamais permettre qu'elles soient renvoyées. De nombreuses fonctionnalités incroyablement intéressantes.

Cypress n'est pas le seul jeu en ville. Il existe plusieurs alternatives à Cypress, dont Playwright, Nightwatch, WebDriver, Codeception, etc. Je vous dirai que l'équipe Go - et ne me citez pas les dates, mais je pense que c'était en 2019 - était sur Cypress. Ensuite, vers 2021-2022, ils sont passés à Puppeteer, qui est soutenu par Google, et depuis février de cette année, ils sont maintenant sur Playwright, qui est soutenu par Microsoft. Personnellement, après plus de 20 ans dans l'enseignement supérieur, j'ai beaucoup de respect et de valeur pour les outils sur lesquels je peux compter pendant longtemps, n'est-ce pas ? Je n'ai jamais eu l'occasion de changer d'outil en 18 mois ; ce n'était pas une option. J'avais besoin de quelque chose sur lequel je pouvais compter pendant 3 à 5 ans, et c'est pourquoi je m'en tiens à Cypress parce que leur documentation est excellente. Ils ont non seulement des documents complets, mais aussi des guides, des tutoriels, des vidéos et des tonnes d'exemples de code, toujours dans le but de vous permettre d'écrire vos tests le plus rapidement possible.

Cela dit, peut-être que l'année prochaine je reviendrai parler de Playwright, je n'en suis pas sûr, mais pour l'instant, c'est Cypress.

D'accord, donc installer Cypress, encore une fois, aussi vite que possible, n'est-ce pas ? C'est aussi simple qu'un npm install. Et c'est ici que nous passons au code live, alors commencez à me souhaiter bonne chance pour que nous ayons de l'internet ici. Donc, je vais aller de l'avant et démarrer ça. [Pause pour l'action]

Ce n'est pas en train de cliquer. C'est parti. Qu'est-ce qui se passe ? Oh, c'est de retour ici. C'est intéressant. Essayons d'effacer npm install, et c'est tout. C'est tout ce que vous avez à faire pour l'installer. Il télécharge automatiquement les dépendances et construit l'application Electron en fonction de votre système d'exploitation. Cela devrait en fait être... voilà, c'est fait.

A partir de là, pour configurer Cypress, tout ce que nous avons à faire est de l'ouvrir. Je vais donc l'ouvrir. Il va construire cette application. La première fois qu'il s'exécute, il dit : " Hé, vous n'avez pas de fichiers de configuration. Que faisons-nous aujourd'hui ? Exécutons-nous des tests de bout en bout ou des tests de composants ?" Nous allons nous concentrer sur les tests de bout en bout. Donc, dès que vous cliquez là-dessus, ça dit : "Ok, je vais configurer les choses pour vous en arrière-plan." Une fois la mise à jour effectuée, vous remarquerez que j'ai un fichier de configuration et une collection de fichiers de soutien, et c'est tout. C'est tout ce que vous avez à faire pour le configurer. À partir de là, il vous suffit de choisir le navigateur dans lequel vous voulez commencer à tester. Aujourd'hui, je fais ma présentation dans Chrome, je vais donc utiliser Firefox. Lancez-le. Et ensuite, comme pour les configurations, dès qu'il apparaît, il dit "Je ne vois pas de fichiers de test". Dans Cypress, les fichiers de test sont appelés fichiers de spécifications. Le message dit : "Voulez-vous que je vous donne des fichiers d'échafaudage, des exemples pour que vous puissiez commencer à construire les vôtres, ou voulez-vous aller de l'avant et écrire votre premier test ?" Allons-y et écrivons notre premier test. Je vais l'appeler "first" et le créer.

En arrière-plan, il a écrit ce fichier dans un répertoire appelé e2e. Est-ce que tout le monde peut voir ce code ? Est-ce que c'est assez gros ? C'est assez gros ? D'accord. Ce que j'aimerais faire, c'est décomposer toutes ces parties au fur et à mesure que nous avançons.

La toute première partie s'appelle "describe". Le bloc describe est simplement un outil d'organisation pour vous. Vous pouvez avoir plusieurs describe à l'intérieur d'un seul fichier spec. Vous pouvez imbriquer des descriptions à l'intérieur d'une description. Il s'agit simplement d'un outil d'organisation. Il prend deux paramètres : un titre que vous voulez voir apparaître dans l'outil de test pour identifier votre groupe de tests, et une fonction de rappel. Nous plaçons nos tests dans la fonction de rappel.

Il contient deux choses : c'est l'endroit où nous plaçons notre test, et il prend un titre, encore une fois, pour s'afficher dans l'outil de test afin que nous puissions identifier le test que nous exécutons, et ensuite une autre fonction de rappel. Cette fonction de rappel est l'endroit où nous plaçons nos actions et nos assertions, où nous allons réellement commencer à faire certaines choses.

Donc, si nous testons une application web, quelle est la première chose à faire ? Vous devez accéder à l'application, n'est-ce pas ? En général, l'une des premières choses à faire ou à utiliser est cy.visit. Cela va charger une URL. Par défaut, il s'agit d'une requête GET. Il va suivre toutes les redirections 300 jusqu'à ce qu'il obtienne un 200, et une fois qu'il a obtenu ce 200, il va attendre que la page soit chargée et s'exécute. Je vais donc retourner dans notre code. Je vais le mettre à jour. C'est un peu difficile à voir avec tous les autres trucs de Zoom, donc si je me trompe, on va s'en contenter. [Pause pour action]

Ça dit : "Le titre de la page est valide." Je ne pense pas avoir totalement raté ça. Nous allons aller de l'avant et exécuter ceci. Exécutons-le. [Pause pour action]

Oh, j'ai oublié de mentionner que je lance DDEV. Quelqu'un connaît-il DDEV ? Quelques-uns d'entre vous ? DDEV est un environnement de développement local. Je l'utilise beaucoup parce que nous l'avons intégré, ce qui me permet de cloner mon site de production, ce dont j'ai également oublié de vous parler. J'ai un site de production. Voici mon site de production. Cela me permet donc, à partir de Platform.sh, de cloner mon site de production localement dans DDEV. Je vais aller le chercher, donc je vais dire DDEV. C'est la bonne, voilà. Voici donc l'URL assignée à mon instance locale. Je retourne dans mon test. Mettons-la à jour. Enregistrez cela et exécutez notre test. [Pause pour action]

Allez-y. Maintenant, nous pouvons voir que nous avons... avec un peu de chance, vous pouvez le voir. Il y a la page d'accueil. C'est le titre que j'ai donné à la description, et ensuite vous nommez le test lui-même. Pour l'instant, le corps du test se contente de visiter le site.

D'accord, une fois que nous avons visité un site, que devons-nous faire ensuite ? En d'autres termes, je veux vérifier que cette page est bien celle que j'attends.

[Réponse de l'auditoire] "Vérifier le titre de la page."

Oui, vérifier le titre de la page, c'est ça ? Vous devez obtenir un élément du DOM et vérifier qu'il contient des données, qu'il a une classe ou qu'il est visible. Nous devons, d'une manière ou d'une autre, valider que la page est bien ce que nous pensions qu'elle allait être. Ainsi, cy.get vous permet d'obtenir un ou plusieurs éléments DOM de la page. Il va céder cet élément DOM à la prochaine chose que nous lui enchaînons. Il va toujours commencer - il est important de s'en souvenir - il va toujours commencer à partir de cy.root, qui est typiquement la racine du document. Ainsi, si je fais cy.get("main") puis une autre chaîne avec cy.get, la recherche ne se limitera pas à cela ; elle remontera jusqu'à la racine. Il y a d'autres façons de le faire, mais pas avec cy.get.

Donc, cy.get est la façon dont nous allons obtenir nos éléments, et tout comme les autres, il va automatiquement continuer à essayer d'obtenir cet élément DOM jusqu'à ce qu'il existe ou que nous atteignions un certain délai d'attente. Donc, je vais retourner dans notre code, et je vais ajouter cy.get. Récupérons le titre - le voilà. Et ensuite, que devons-nous faire ? Lui dire ce qu'il devrait être, d'accord ? La méthode que nous utilisons est should. Nous utilisons la méthode should sur cet élément DOM, et c'est ce qui va créer notre assertion ou notre validation. Cette méthode accepte une chaîne de caractères compatible avec Chai. Chai est une bibliothèque d'assertions pour le développement piloté par le comportement (BDD) et le développement piloté par les tests (TDD). Elle vous permet d'utiliser des mots simples pour décrire l'assertion ou la validation que vous essayez de faire. Il va toujours renvoyer le même sujet qu'il a reçu, donc si je lui donne l'élément title et que je fais une assertion, s'il réussit, il va le renvoyer au suivant, ce qui signifie que je peux enchaîner les assertions. Il va automatiquement continuer à essayer d'obtenir une assertion positive jusqu'à ce qu'il atteigne un délai d'attente ou qu'il échoue.

Donc, dans ce cas, je vais casser ceci la première fois juste pour que nous puissions le voir. Je vais dire que devrait contenir "WP Campus 2023". Exécutons ce test, et remarquons qu'il échoue parce que ce n'est pas 2023, n'est-ce pas ? J'ai donc une jolie petite coche rouge - vous ne pouvez peut-être pas la voir - à côté du test, indiquant que le test a échoué. L'assertion n'a pas réussi. Maintenant, je reviendrai et j'espère que je pourrai corriger cela. Nous y voilà. Maintenant, il est en fait... il surveille aussi, donc il va surveiller votre test et le réexécuter automatiquement. Il a probablement déjà réexécuté ce test, et il l'a fait. J'ai maintenant une belle affirmation verte. Je suis également daltonien, donc si ce n'est pas vert, que quelqu'un me le dise s'il vous plaît. Je suppose que c'est vert. Nous avons donc une assertion verte et une coche verte, ce qui signifie que vous venez de terminer votre premier test. Nous y voilà.

Je sais que c'est un test très simple, mais pour moi, la partie la plus difficile de l'apprentissage d'une nouvelle chose est de l'installer, de la configurer et de faire quelque chose. Donc, si vous pouvez revenir en arrière et l'installer, le configurer - ce qui consiste essentiellement à l'ouvrir - et ensuite écrire un simple test de "aller sur ma page d'accueil et s'assurer que le titre est correct", vous l'avez maintenant incorporé dans votre flux de travail. Le prochain sera d'autant plus facile.

En fait, alors que vous commencez à travailler à la rédaction de votre prochaine série de tests, il y a certaines choses à garder à l'esprit. La première est que la partie la plus difficile de l'écriture des tests est de savoir ce qu'il faut tester. C'est la partie la plus difficile. Je vous suggère donc, la prochaine fois que l'on vous confie une tâche, une fonctionnalité censée être intégrée à votre site, de noter toutes les étapes que vous suivrez pour la vérifier manuellement. Allez-y et dites : "D'accord, j'ai cliqué ici, j'ai cliqué ici, j'ai cliqué ici, j'ai cliqué ici", et à la fin, "Voilà ce qui devrait se trouver sur cette page, voilà comment elle devrait réagir". Voilà comment elle devrait réagir." Continuez à décomposer ces éléments en étapes de plus en plus petites, puis convertissez ces étapes et ces actions en un test. Continuez ensuite à exécuter ce test jusqu'à ce que vous compreniez - tant que la fonctionnalité fonctionne - comment vous assurer que vous l'écrivez correctement. Assurez-vous de tester à la fois les chemins heureux et les chemins malheureux.

Ce que je veux dire par là, c'est que si nous testions un formulaire de connexion, par exemple, un chemin heureux serait le suivant : "Je mets un nom d'utilisateur et un mot de passe dans le formulaire : Je saisis un nom d'utilisateur et un mot de passe corrects, je clique sur Envoyer, j'arrive dans la zone d'administration et mon nom d'utilisateur apparaît en haut à droite. C'est un chemin heureux. Un chemin malheureux serait : Je saisis un nom d'utilisateur et un mot de passe incorrects, je clique sur Envoyer, je reviens au formulaire et j'ai un message d'erreur. Nous devons donc nous assurer que nous testons le chemin malheureux pour nous assurer que l'application agit et fonctionne comme nous l'attendons, même si l'utilisateur ne suit pas les étapes correctes.

Un bon test doit couvrir trois phases. La première consiste à configurer l'état de l'application - nous reviendrons plus tard sur l'état de l'application. La deuxième consiste à effectuer ces actions, toujours en imitant l'utilisateur, en exécutant les étapes nécessaires pour tester cette fonctionnalité. Enfin, la dernière étape consiste à formuler une assertion sur l'état résultant. Il est possible que l'on parle de "arranger, agir et affirmer" ou que l'on parle de "donner, quand, alors". Ainsi, si nous revenons au premier test, étant donné que je suis un utilisateur anonyme, lorsque je visite la page d'accueil, le titre de la page devrait être "WP Campus 2024". Vous comprenez ? Pensez donc en ces termes : étant donné un certain état de l'application, lorsque je fais ces étapes, l'application devrait être ainsi.

L'autre élément auquel il faut penser lorsque vous écrivez ces tests est qu'il faut essayer de les rendre indépendants les uns des autres. Ce que je veux dire par là, c'est que si j'ai quatre tests, je ne veux pas que le test trois dépende de l'état créé par le test un. En effet, premièrement, le test 1 peut réussir de manière incorrecte et me laisser avec un état inapproprié ; ou deuxièmement, il peut échouer et me laisser avec un état qui va affecter négativement le test 3. Nous voulons donc nous assurer que chaque test peut s'exécuter indépendamment des autres.

Êtes-vous prêt à écrire le deuxième test ? C'est ce que je cherche à faire. D'accord, je vais venir ici et créer un deuxième fichier. Allez-y. Nous allons créer un nouveau fichier JavaScript, que j'appellerai auth.cy.js. Disons que je vais décrire, et nous allons décrire ceci comme un test d'authentification. Ensuite, nous avons notre callback. Et puis je vais le faire peut auth. Jusqu'à présent, rien de très compliqué. Une fonction de rappel, beaucoup de rappels. Et ensuite, quelle est la première chose à faire si l'on veut tester le formulaire de connexion ? Je dois visiter le formulaire de connexion, n'est-ce pas ? Je vais donc aller à cy.visit. Je vais retourner à DDEV, je vais reprendre mon adresse, revenir et dire, "Allez visiter avec wp-login.php". Maintenant, est-ce que quelqu'un peut prévoir un problème que je viens de créer entre auth.cy.js et first.cy.js, spécifiquement dans la visite?

Où se trouve l'URL en ce moment ? "Homepage". Page d'accueil de l'endroit où il est exécuté ? "Local". Que se passe-t-il si je dois exécuter mes tests de bout en bout dans un environnement de développement partagé ? Et si je dois les exécuter dans un environnement de mise en scène, ou un environnement PR, ou ailleurs ? Très bien, nous devons donc parler brièvement de la configuration. L'une des options du fichier de configuration s'appelle baseUrl. baseUrl nous permet de définir un domaine, et ensuite tous les appels à cy.visit ou cy.request qui sont relatifs auront cette valeur ajoutée. Mais ce qui est vraiment génial, c'est qu'il peut être remplacé par d'autres variables d'environnement. Cypress a donc un ordre de traitement pour les variables d'environnement. Ainsi, pour cette variable spéciale baseUrl ou toute autre variable d'environnement que nous devons créer, nous pouvons soit les mettre dans config, mais nous pouvons aussi écrire un fichier .env qui les remplace. Ou bien, si le système sur lequel nous lançons cypress run ou cypress open a des variables d'environnement précédées de CYPRESS_, il les analysera automatiquement et remplacera toutes les autres. Ou bien, au moment où nous lançons Cypress, nous pouvons également passer des dérogations pour la configuration ou ces variables d'environnement. Ou - ce n'est même pas sur la diapositive - dans un test individuel, vous pouvez remplacer une configuration ou ces variables d'environnement, ce qui nous donne beaucoup de flexibilité. Cela signifie que nous pouvons écrire nos tests de manière à pouvoir les exécuter n'importe où sans avoir à nous soucier de modifier le test pour un environnement spécifique.

Je vais donc ouvrir le fichier de configuration et y ajouter l'URL de base. Je vais dire que normalement tout le monde dans l'équipe utilise https://local.site/, et que je suis l'intrus. D'accord, maintenant si j'exécute cela maintenant - regardez, Cypress s'est fermé - je reviens et il dit, "Hey, je ne peux pas y aller parce qu'il n'y a rien là", n'est-ce pas ? Donc, si je reviens, que je ferme Cypress d'abord - je ferme Cypress - je vais réexécuter cela. Je reviens dans mon environnement de test. Pouvez-vous voir en bas ? Avec un peu de chance. Je vais procéder à une exportation en réglant baseUrl sur l'adresse que j'ai utilisée plus tôt. D'accord, je vais aller de l'avant et faire cela. Je referai npx open. [Pause pour action]

Oups, trop loin. Nous y voilà. Et puis dans mes tests ici, je vais mettre à jour ces deux tests. [Pause pour l'action]

Mettez à jour ces tests. [Pause pour l'action]

Celui-là, et mon test d'authentification. Voilà. Et si nous les sauvegardons et retournons à Cypress, relançons l'environnement de test. [Pause pour l'action]

Allez-y. Et maintenant, si je lance first.cy.js, nous retournons toujours à notre instance locale. Et si je lance auth.cy.js, nous arrivons à la connexion. Maintenant, j'ai besoin de faire une demande de RP, et j'ai un flux de travail qui construit une copie de cet environnement. Je n'ai pas besoin de modifier mon test ; tout va fonctionner. Je vais pouvoir les exécuter directement sur cet environnement sans avoir à modifier mon test.

Maintenant, si nous testons le formulaire de connexion, que devons-nous faire ensuite ? Taper le nom d'utilisateur ? Nous devons saisir un nom d'utilisateur et un mot de passe. L'un des aspects intéressants de cet environnement est que si vous remarquez ce petit bouton à côté de l'URL, vous obtiendrez un sélecteur d'élément suggéré - beaucoup de mots. Je vais donc appuyer sur ce bouton et, lorsque je le survole, il me dit : "Voici tous les éléments que vous pouvez sélectionner." Je clique dessus, et il me donne la possibilité de le copier dans mon presse-papiers. Je peux alors retourner dans mon test et dire : "Très bien, nous allons aller chercher cet élément." Maintenant, une chose que je suggère et que j'ai apprise, c'est d'aller de l'avant et de faire un clear() sur l'élément. Cela permet d'effacer l'élément au cas où il y aurait un texte de remplacement ou autre. Et à partir de là, je peux taper "bob". Et quel est le prochain élément dont nous avons besoin ? Le mot de passe. Parfois, il n'y a pas de réexécution ; la sélection n'est pas toujours refaite. Reprenons-le. Allez là-dedans, et nous vous laisserons coller. Nous y voilà. Et un autre clear(), et un autre type "123". Sauvegardons cela. Revenons à notre test. Maintenant, nous avons "bob" et "123". Quelle est la dernière chose à faire ?

["Entrer".

J'ai entendu deux choses. J'ai entendu "entrer" et j'ai entendu "cliquer". Vous pouvez faire les deux. Vous pouvez donc simuler des pressions sur des boutons ou des touches en utilisant les accolades et une étiquette courte pour cette touche. C'est ce que je vais faire. Ou, si nous voulons... J'ai tout effacé - oups - "123". Permettez-moi de revenir et de saisir le nom du bouton. Revenez ici, prenez-le et faites un clic. Wow, vous êtes un public difficile ; vous ne riez pas. Je pense que c'est plutôt cool.

Alors, quelqu'un peut-il prévoir un problème avec ce que j'ai fait ici ? "SSO". Oh, eh bien, le SSO pourrait être une chose, qui met en évidence... oui, vous mettez en évidence le problème. Qu'est-ce qui ne va pas ? C'est codé en dur, n'est-ce pas ? Ce n'est pas ce que nous voulons. Mais nous avons la possibilité d'ajouter des variables d'environnement, n'est-ce pas ? Je peux donc retourner dans ma configuration et dire : "Hé, je veux ajouter des variables d'environnement." Oups, ce n'est pas la bonne touche. Essayons celle-ci. Nous y voilà. Et je peux dire, "Hey, je veux test_user, et je veux que test_user soit par défaut bob." Oh, nous ferons "bob2" pour changer, et ensuite j'ai besoin de test_userPass, et je veux que la valeur par défaut soit "4567". C'est ça ? Maintenant, si je mets cela à jour et que je reviens dans mon test, je peux me débarrasser de ces valeurs statiques, et je peux dire, "Hey, je veux utiliser Cypress.env et je veux que vous récupériez test_user, et je veux que vous alliez ici et je veux que vous récupériez Cypress.env('test_user_pass)." Et si nous sauvegardons cela, en supposant que je n'ai pas fait de fautes de frappe, cela utilise bob2 maintenant. Ce qui signifie que dans un autre environnement, je peux ajouter ces variables d'environnement et qu'elles seront automatiquement prises en compte.

Très bien, il y a maintenant un élément que je voudrais mentionner rapidement, et c'est que vous devez décider d'une stratégie pour gérer l'état. Cette diapositive traite de l'état d'un utilisateur puisque nous testons un utilisateur, mais cela s'applique également à l'état de l'application elle-même. Une stratégie consiste donc à bloquer les requêtes. Vous vous souvenez que j'ai mentionné l'interception ? Nous pourrions donc intercepter une requête vers wp-login, l'attraper et renvoyer des informations statiques sur les cookies et les informations de session. C'est bien parce que c'est très rapide, et je n'ai pas besoin d'avoir un environnement - je n'ai pas besoin de mettre en place une base de données. Mais remarquez qu'il fait la grimace parce que cela nécessite des fixtures. Les fixtures sont les données statiques que vous voulez renvoyer. Si les informations relatives aux cookies et à la session changent dans l'application, je dois me rappeler de revenir en arrière et de mettre à jour les informations statiques que j'ai sauvegardées. Mais il ne s'agit pas non plus d'un véritable test de bout en bout, n'est-ce pas ? Dans un test de bout en bout, nous voulons vraiment essayer de reproduire le plus fidèlement possible ce que vit l'utilisateur final.

La stratégie suivante est donc celle de l'utilisateur statique, qui consiste à aller dans notre système et à créer un utilisateur que nous utiliserons dans nos tests. C'est bien parce qu'il s'agit alors d'une véritable session de bout en bout, n'est-ce pas ? Nous avons une base de données, nous avons un véritable utilisateur. Mais cela signifie que nous devons disposer d'un environnement dans lequel nous pouvons placer une base de données, et que nous allons devoir configurer la base de données - qu'il s'agisse d'exporter à partir d'un autre système et de l'importer ensuite, ou peut-être d'automatiser l'installation de WordPress et de configurer cet espace. L'inconvénient, cependant, est que - en particulier dans WordPress - votre utilisateur, au fur et à mesure qu'il fait des choses, l'état de ce qui est associé à lui change et est stocké dans la base de données, n'est-ce pas ? Nous nous retrouvons donc avec un état suspendu ou un état empilé, ce qui pourrait affecter les réexécutions du test ou les tests futurs parce que nous avons cet état sauvegardé avec l'utilisateur.

Le dernier type d'utilisateur est un utilisateur dynamique, dans lequel vous allez supprimer et recréer l'utilisateur avant chaque test. Il s'agit d'un véritable test de bout en bout, car nous recréons exactement l'expérience de l'utilisateur. Nous n'avons pas à nous préoccuper de la mutation de l'état ou de l'état en suspens, mais nous devons à chaque fois démonter et reconstruire cet état avec la base de données, ce qui signifie que c'est un peu plus lent, un peu plus complexe.

Eh bien, pour les besoins d'aujourd'hui, je vais - si je peux trouver les bonnes clés - demander à DDEV de créer un utilisateur pour moi, et je vais lui demander de créer bob2. Je vais prendre ce mot de passe pour avoir un utilisateur réel. Copiez-le, revenez à Cypress, je vais fermer mon test, fermer Cypress et revenir. Et avant de le lancer, je vais exporter ces valeurs. D'accord, donc je fais une exportation de test_user, donc maintenant nous allons utiliser bob2 et ce mot de passe. Maintenant, relançons Cypress. Relançons nos tests de bout en bout.

[Pause pour action]

Maintenant, si nous allons au test d'authentification, TA-DA ! nous avons un vrai utilisateur. Vous pouvez vérifier que cela a fonctionné parce que si vous n'entrez pas le bon nom d'utilisateur et le bon mot de passe, vous revenez à la connexion, mais cela envoie un 200, ce qui signifie techniquement que le test est réussi. Alors, comment pouvons-nous valider que cela a fonctionné ? En récupérant le nom d'utilisateur. Donc, je vais aller ici, je vais utiliser ce sélecteur, je vais dire, "Hey, donnez-moi ça." Je vais l'attraper, retourner dans mon test et dire "Ok, après avoir cliqué", ça va automatiquement attendre que la page suivante se charge, alors je peux dire "Prends ça". Je vais descendre parce que ça devient un peu long, et je vais dire, devrait contenir, et puis je vais revenir et dire Cypress.env('test_user'). Si je l'écris correctement. Maintenant, si je l'enregistre, nous lançons le test. Et voilà, c'est fait. Voilà notre assertion. Elle est belle et verte. Nous avons réussi. C'est bon ? Tout le monde a réussi jusqu'à présent ?

Ok, alors maintenant disons que nous voulons étendre le test. Nous venons de rédiger le deuxième test, mais nous voulons le prolonger. Ne regardez pas cela ; oubliez que vous l'avez vu. Je suis désolé, je suis allé trop loin. Nous voulons donc prolonger ce test. Disons que maintenant nous voulons avoir un deuxième test où nous pouvons ajouter un type de post personnalisé. Peut-être qu'ils ont un rôle personnalisé - cet utilisateur a un rôle personnalisé - et nous voulons vérifier qu'ils peuvent créer ce type de post et le voir. Une chose que je n'ai pas mentionnée est que lorsque vous exécutez Cypress, lorsqu'il exécute chaque test, c'est comme s'il utilisait le mode incognito ou le mode privé pour chaque test. Cela signifie qu'il ouvre une instance, l'exécute, la termine et la ferme, ce qui signifie que si j'essaie d'aller ici et de faire cy.visit et ensuite de faire quelque chose comme wp-admin/edit.php, que va-t-il se passer ? Il réussira à obtenir un 200, mais il n'ira pas au bon endroit, n'est-ce pas ? Dois-je donc copier tout ce contenu et le coller dans le prochain test ?

[Réponse de l'auditoire] "Non."

D'accord, vous secouez la tête, c'est la bonne réponse. Bon, au lieu de cela, vous vous souvenez que j'ai dit qu'il nous donnait un tas de fichiers de soutien ? L'un de ces fichiers s'appelle "commands.js". Il nous permet de créer nos propres commandes personnalisées. Je peux donc utiliser Cypress.commands.add(). Le premier paramètre est le nom de la méthode, cette nouvelle commande que vous voulez appeler, donc je dirai "wplogin". Le second est - devinez ce qu'est le second ? Une fonction de rappel, c'est ça ? La fonction de rappel. Et ensuite, à l'intérieur d'ici, nous pouvons mettre ce code.

Maintenant, est-ce que je veux toujours utiliser ces variables d'environnement ? Probablement. Peut-être ? Et si je veux tester plusieurs utilisateurs ? Au lieu de cela, je pourrais dire, "Très bien, la fonction de rappel acceptera un nom d'utilisateur et un mot de passe." Maintenant, je peux aller ici et effacer tout ça. Puis ceci... [Pause pour l'action]

Tout ça, voilà. Et dire, "Nom d'utilisateur, nom d'utilisateur ici." Oh, c'était le mot de passe, désolé, ça va échouer. Essayez "Mot de passe", c'est parti. Et puis, ici, faites "Nom d'utilisateur". Ensuite, dans mon test d'authentification, je peux dire cy.wplogin() et lui donner - mauvaise clé - Cypress.env('test_user') et Cypress.env('test_user_pass'). L'un des inconvénients des démonstrations en direct est que je ne suis pas un dactylographe rapide. Très bien, voyons maintenant si cela a fonctionné. Voilà notre test d'authentification. Le premier a dit : "Oui, regardez, il a exécuté tout le code, et nous..." Oh, c'est le bon moment pour vous montrer - vous vous souvenez de ce voyage dans le temps ? Voici tous les différents états. Vous pouvez voir qu'il a obtenu le nom d'utilisateur, qu'il l'a tapé, qu'il a effacé le suivant et que le mot de passe a été tapé. Cliquez sur soumettre, suit, suit, suit, jusqu'au bout, et voilà notre assertion.

C'est super. D'accord, disons maintenant que je veux faire ce prochain test. Dois-je copier cette ligne et la coller ?

[Non.

Non. Donc, tout comme avec WordPress, Cypress vous donne des crochets. L'un de ces crochets consiste à exécuter quelque chose avant chaque test. Devinez ce que cela prend ? Oups, c'est trop de fonctions de rappel. Oui, tout est une fonction de rappel. Et donc maintenant, je peux prendre cette ligne - en fait, faisons-le de cette façon ; elle est sur le côté de mon écran, je ne peux pas la voir - la couper de là, la mettre ici. Maintenant, si j'exécute cette ligne, remarquez qu'elle l'a fait non seulement pour la première, mais aussi pour la deuxième. Et maintenant, à la fin, il a fait la page d'édition.

D'accord, mais il se rend sur le formulaire, récupère les éléments et insère les informations à chaque fois. Deux tests, ce n'est probablement pas grave. Mais qu'en est-il si nous avons 15 tests ? Ne serait-ce pas bien si, au lieu de... c'est ce que je voulais que vous voyiez tout à l'heure - si nous pouvions sauvegarder les données de la session ? C'est ce que je voulais vous montrer tout à l'heure. Nous avons donc cette possibilité dans Cypress. Il prend une session que nous avons créée et la stocke sur la base d'un identifiant. Il prend quatre arguments. Je parie que vous pouvez deviner ce que sont certains d'entre eux. Le premier est un ID sur la façon dont nous voulons identifier cette session. Le suivant est un callback où nous exécutons notre code d'installation. La troisième option est un autre callback où, si nous restaurons une session, nous pouvons valider la session et si la validation échoue, le callback de configuration sera réexécuté. Et la quatrième option est de savoir si nous voulons ou non partager cette session sauvegardée avec d'autres fichiers spec.

Je vais donc ajouter ceci à notre code. Je vais retourner dans les commandes, prendre tout cela, le couper, et dire cy.session. J'utiliserai le nom d'utilisateur comme identifiant, je définirai le rappel, puis je collerai nos informations. Maintenant, si je sauvegarde et exécute ces tests, la première fois, il dit "Hey, j'ai besoin de créer la session bobby2 ", et il exécute toutes ces étapes, comme plus tôt. Mais la deuxième fois, il dit "J'ai besoin de la session bobby2, mais je vais la restaurer", de sorte qu'il n'a pas à répéter ce processus.

C'est énorme et très important parce que beaucoup d'entre vous auront probablement besoin d'effectuer des tests de session authentifiée. C'est l'une des parties les plus difficiles que j'ai rencontrées, et la raison en est qu'entre la version 12 et la version 13, Cypress a introduit une fonctionnalité qui facilite grandement la sauvegarde des informations de session. Si vous cherchez en ligne comment faire, vous trouverez souvent des articles périmés et des articles de blog qui ne sont plus d'actualité.

Dans les dernières minutes, j'aimerais vous donner quelques bonnes pratiques à garder à l'esprit lorsque vous commencez à écrire ces tests. Tout d'abord, si vous n'avez pas besoin de tester un formulaire de connexion, ne vous embêtez pas à intégrer Chrome dans le processus. Au lieu de cela, traitez-le de manière programmatique. Je veux dire par là qu'au lieu de visiter la page, faites un POST vers la page wp-login.php. Tout le reste reste identique, y compris le nom de la méthode et la configuration de la session, mais je publie ces informations de manière programmatique, ce qui m'évite de faire apparaître Chrome.

Le point suivant à considérer est l'un des compromis lors de l'utilisation de Cypress, en particulier si vous êtes déjà un développeur JavaScript : vous ne pouvez pas assigner les valeurs de retour d'une commande Cypress à une variable ou à une constante ; vous ne pouvez accéder à ces retours que par l'intermédiaire de fermetures et d'alias. Certains trouvent cela dérangeant, mais c'est le compromis à faire pour gagner en rapidité. Pour plonger rapidement dans Cypress, vous devez travailler dans leur cadre d'opinion.

Je l'ai déjà mentionné, mais essayez de définir l'état avant chaque test, de sorte que chaque test puisse être exécuté indépendamment à n'importe quel moment. Essayez également d'éviter d'utiliser des sélecteurs fragiles. Les identifiants et les classes peuvent changer, et même l'emplacement d'un élément peut changer sans que cela soit visible. Cypress suggère d'utiliser des attributs de données lorsque c'est possible, en définissant des attributs de données uniques qui ne changent pas, afin de s'assurer que vos tests ne sont pas fragiles.

OK, petit quiz : qui peut définir les tests de bout en bout ? N'importe qui ? C'était l'un de mes objectifs et je ne veux pas échouer ! Quelqu'un !

[Membre de l'auditoire] : tester de bout en bout

Tester toutes les parties, du début à la fin ! Nous allons essayer d'imiter un utilisateur qui parcourt les chemins de notre application et de valider, à partir de ce qu'il a fait, que notre application a répondu correctement. Quelqu'un peut-il me citer un avantage des tests de bout en bout ?

[Membre de l'auditoire] : gagner du temps !

Gagner du temps ! Beaucoup plus rapide. En gros, on fait des tests manuels, mais beaucoup plus vite, parce que l'ordinateur est beaucoup plus rapide que vous. Très bien, est-ce que tout le monde se sent à l'aise avec ce qu'est Cypress, l'installer, le configurer - vous venez juste de l'ouvrir - et peut-être écrire votre premier test ?

[Membre de l'auditoire] : J'ai une question

Bien sûr.

[Membre de l'auditoire] : J'ai une question : Dans le code, vous avez écrit Cypress avec une majuscule et ensuite cy. Quelle est la différence ?

Cypress fait référence à l'application globale, et vous l'utilisez pour accéder aux variables d'environnement et autres paramètres globaux. Pour les autres commandes, vous utilisez cy dans vos tests. Vous pouvez consulter la documentation pour plus de détails.

Alors, est-ce que tout le monde se sent à l'aise pour écrire ce premier test ? Vous sentez-vous assez à l'aise avec les meilleures stratégies pour écrire vos deuxième et troisième tests ?

J'aimerais maintenant vous montrer un scénario réel pour vous donner une idée de la façon dont tout cela s'articule. L'une des raisons pour lesquelles j'aime Cypress est qu'ils ont une action GitHub bien documentée et stable. Cela signifie que dans mes flux de travail GitHub, lorsque je crée une demande d'extraction, Cypress peut automatiquement exécuter tous mes tests de bout en bout. Chez Platform, nous avons également une intégration GitHub. Lorsque vous créez une demande d'extraction, le code nous est envoyé. Nous clonons ensuite votre environnement de production dans un environnement isolé avec le code de la demande d'extraction, nous lançons l'environnement cloné, nous générons une URL éphémère et nous renvoyons cette URL à GitHub.

Lorsque j'exécute l'action Cypress, je peux transmettre l'URL de l'environnement de production cloné. Ainsi, lorsque j'exécute les tests de bout en bout, ils correspondent exactement à ce que j'attendrais en production. Cela renforce la confiance dans le code avant le déploiement.

Je vais vous montrer cela en pratique. J'ai une pull request ouverte pour mon site de production, et en bas avec mes vérifications, je peux voir que l'intégration de la plateforme est terminée, et qu'elle a déployé cet environnement PR. En l'ouvrant, je peux voir un clone de mon environnement de production assigné à la demande d'extraction. Je vois aussi que mes tests de bout en bout ont échoué. En regardant les détails, il est indiqué que six tests ont réussi et un a échoué. Si vous intégrez votre projet à Cypress Cloud, vous pouvez rejouer les tests en cas d'échec. Vous pouvez réexécuter le test, voir les étapes qu'il a exécutées sur le côté gauche et voir l'état de l'application sur le côté droit. Dans ce cas, le test a échoué parce que l'icône de la corbeille était absente, ce qui a empêché un utilisateur de supprimer son message. Je peux maintenant utiliser les outils de test pour déboguer le problème.

Très bien, je pense que nous avons 15 minutes pour les questions. Quelqu'un a-t-il des questions à poser ?

QUESTIONS ET RÉPONSES

Remarque : il s'agit d'hypothèses en raison de la mauvaise qualité de l'audio.

[Membre de l'auditoire] : Lorsque vous décidez ce qu'il faut tester de bout en bout, est-ce toujours une fonctionnalité frontale que vous testez ? ou Comment décidez-vous globalement de ce qu'il faut tester ?

[Paul] : Cet outil est destiné aux applications web qui se trouvent le plus souvent à l'intérieur d'une interface web. Il existe d'autres outils qui permettent de tester directement les API. Vous pouvez simuler des tests d'API si vous en avez vraiment besoin, mais cet outil n'est pas conçu pour cela. Lorsque vous devez imiter le comportement d'un utilisateur à travers l'application et valider une caractéristique ou une fonction, c'est ce que vous utilisez.

[Membre de l'audience] : Lorsque vous travaillez avec WordPress, vous modifiez souvent une grande partie du noyau. Est-il utile, ou existe-t-il un package de base pour tester le noyau avant de tester les différentes parties de l'application ? Est-ce qu'il y a une bibliothèque que l'on peut utiliser pour s'assurer que WordPress fonctionne d'abord et ensuite tester nos fonctionnalités en couches ?

[Paul] : Core est passé à Playwright, donc ils ont les tests Playwright ; ils ont abandonné le test Cypress il y a des années, donc " non " malheureusement. Je dirais que si c'est un élément crucial, alors je regarderais Playwright et de cette façon, vous aurez leur test que vous pourrez exécuter. Ce n'est pas comme si Playwright était mauvais. Je ne veux pas que l'on pense qu'il ne faut pas l'utiliser. C'est juste qu'il est nouveau ; il n'a que quelques années, la documentation existe mais n'est pas aussi complète. Donc, si c'est une caractéristique importante, je dirais d'aller voir Playwright et de cette façon, vous aurez leur test que vous pourrez exécuter.

[Membre de l'auditoire] : Je ne sais pas si vous avez besoin de tester tout ce que Core teste. Vous savez, juste une vue d'ensemble. Tu vois ce que je veux dire ?

[Paul] : C'est un autre exemple. Nous gérons, quand vous faites des déploiements en un clic, nous les gérons et donc j'ai toutes les mises à jour automatisées. Et dans le cadre du test, je fais une vérification rapide des fonctionnalités de base pour m'assurer que les fonctionnalités les plus importantes sont là et qu'aucun de nos codes personnalisés n'a affecté négativement l'une ou l'autre des fonctionnalités de base. Donc, oui. Je veux dire que je l'ai fait et il n'y a aucune raison pour que vous ne le fassiez pas.

[Membre de l'auditoire] : Pouvez-vous interagir avec ce clone ? Si vous voulez faire vos propres tests manuels ou autre chose ?

[Paul] : Non, vous ne pouvez pas. Il va sauvegarder l'état de chaque clone mais vous ne pouvez pas cliquer et faire d'autres choses.

[Membre du public] :
Vous ne pouvez pas vous connecter en tant que vous-même et essayer des choses ? Il faudrait écrire un test pour cela ?

[Un autre membre du public] :
Je pense que vous demandez simplement : pouvez-vous, en tant qu'humain, visiter l'environnement de relations publiques de la plateforme ?

[Membre de l'auditoire initial] :
Oui.

[Paul] : Oh, absolument ! Je pensais que vous parliez des captures d'écran de l'environnement de test que nous avons vues et que Cypress a présentées pour nous montrer le test.

[Membre de l'auditoire] : Non, non : Non, non. Je parlais du clone utilisant le nouveau code. Ce serait cool de pouvoir interagir avec ça.

[Paul] : Oui, c'est tout à fait possible. En fait, vous pouvez aussi vous en servir pour écrire votre test. Lorsque vous allez le vérifier, utilisez-le pour enregistrer toutes les étapes que vous suivez. Je suis désolé, je n'ai pas compris. Quelqu'un d'autre ?

[Membre de l'auditoire] : Est-ce que vous avez des régressions visuelles dans votre stack que vous faites avec ces outils ?

[Paul] : C'est un outil séparé que j'utilise et je vais oublier son nom... Il a une tête de singe... oh j'ai oublié le nom du test de régression visuelle... et je me souviendrai environ deux secondes après que vous soyez tous partis du nom de cet outil... Il y a une source ouverte - backstop ! Backstop, nous utilisons backstop pour les tests de régression visuelle afin de nous assurer qu'il n'y a pas de régressions visuelles. Si vous n'êtes pas familier avec les tests de régression visuels, voici ce qu'il fait : vous lui donnez un site de production ou un site de référence qui devrait être correct, puis vous lui donnez votre environnement de test, votre environnement de développement, de mise en scène, de RP, peu importe. Il effectue des captures d'écran des emplacements que vous avez identifiés et les compare. Si la différence est supérieure à un certain pourcentage que vous définissez, il signale qu'il s'agit d'une erreur ou qu'il y a eu une régression. Donc, oui, vous pouvez absolument l'ajouter et je vous encourage à ajouter autant de tests automatisés que possible pour réduire le nombre d'heures de travail que vous devez consacrer à ces choses, parce que je sais que dans l'enseignement supérieur, vous n'avez pas le temps ; vous avez juste plus de responsabilités, pas plus de personnes. Donc, chaque fois que vous pouvez automatiser ce genre de choses, c'est mieux. D'autres questions ?

[Membre de l'auditoire] : Quelqu'un a mentionné le SSO. Nous avons essayé behat il y a quelques années et nous avons eu du mal à nous connecter à WordPress pour faire des choses internes. On pouvait faire du frontend, mais pas se connecter, poster, donc...

[Paul] : En supposant que vous ayez un utilisateur test dans le système d'authentification unique où vous pouvez avoir le mot de passe quelque part pour l'utiliser, vous devriez pouvoir le faire. Je ne prévois aucun problème avec le SSO. Je ne peux pas dire que je l'ai testé récemment avec le SSO, mais cela devrait fonctionner.

[Un autre membre du public] : Nous ne l'avons pas fait avec Cypress mais nous l'avons fait avec Puppeteer avec AWS. C'est la même chose, et oui... ça marche comme il faut.

[Paul] : C'est un bon point. Que vous utilisiez Cypress ou Playwright, les concepts sont fondamentalement les mêmes. Ce sont juste les spécificités de la façon dont vous écrivez le test, n'est-ce pas ? Donc si vous commencez à jouer avec Cypress et que vous décidez que cela ne va pas fonctionner pour nous, ce n'est pas comme si vous aviez vraiment perdu quelque chose, sauf peut-être un peu de temps pour apprendre les spécificités. Mais vous pouvez simplement prendre la même idéologie de test et la transférer au produit suivant. D'autres questions ? Tout le monde est prêt pour le déjeuner ?

[Animateur de la salle] : Il y en a une en ligne. Une question en ligne.

[Paul] : Oh, donc le démontage et l'installation. Oui, dans l'état de l'application. Quand j'ai dit que je testais les utilisateurs pour WordPress core, ce que je dois faire c'est que j'ai des fonctions que j'ai écrites dans Cypress qui vont se connecter à cet environnement et créer l'utilisateur dynamique comme je l'ai fait. En fait, il supprime d'abord l'utilisateur, supprime tous les messages, supprime tout ce qui concerne l'utilisateur. Ensuite, il crée l'utilisateur, récupère le mot de passe, le définit en tant que variable d'environnement Cypress et démarre Cypress. C'est ainsi que je gère cela et vous devrez faire la même chose. Vous pouvez le faire dans les actions GitHub si vous le souhaitez, il n'y a aucune raison pour que vous ne le fassiez pas, mais puisque Cypress a ces crochets, vous pouvez faire un crochet before et dire avant que je lance un de ces tests authentifiés, que je lance tous ces trucs d'installation ou le beforeEach, alors qu'avec les actions GitHub, il va falloir que ce soit principalement avant et après.

Je crois que c'est tout ce qu'il y a à dire en ligne. Y a-t-il d'autres questions ? Encore une fois, je serai ici pour le reste du temps jusqu'à samedi. N'hésitez pas à m'attraper, à me poser d'autres questions sur n'importe quel sujet. J'adore l'automatisation, donc si c'est des tests, DevOps, n'importe quoi, j'adore ça.