Livraison stable de produits avec Cypress

Fei Han

February 7, 2021

Ecosystem

Le tableau de bord Apache APISIX est conçu pour rendre aussi simple que possible l'utilisation d'Apache APISIX via une interface frontale. Depuis le lancement du projet, il y a eu 552 commits et 10 versions. Avec une telle rapidité d'itération du produit, il est essentiel de garantir la qualité du produit open source. Pour cette raison, nous avons introduit un module de test E2E pour assurer une livraison stable du produit.

Qu'est-ce que le Front-End E2E ?

E2E, qui signifie "End to End", peut être traduit par des tests "de bout en bout". Il imite le comportement de l'utilisateur, en commençant par un point d'entrée et en exécutant des actions étape par étape jusqu'à ce qu'une tâche soit terminée. Des tests solides empêchent les modifications de code de rompre la logique originale.

Pourquoi Cypress

Nous avons utilisé Taiko, Puppeteer, TestCafe et Cypress pour écrire des cas de test lors de la création de routes pendant la période de recherche de sélection, et nous avons utilisé chaque framework de test pour écrire des cas afin d'expérimenter leurs fonctionnalités respectives.

Taiko se caractérise par un sélecteur intelligent, qui peut localiser intelligemment les éléments que vous souhaitez manipuler en fonction du contenu textuel et des relations de position, et a un faible coût de démarrage, ce qui vous permet de terminer rapidement les cas de test. Cependant, il n'est pas convivial lors de l'écriture des cas de test. Lorsque l'utilisateur quitte le terminal par erreur, tous les cas de test écrits sont perdus, et si vous souhaitez exécuter un cas de test complet, vous devez l'utiliser avec d'autres exécuteurs de tests, ce qui augmente sans aucun doute le coût d'apprentissage pour l'utilisateur.

Puppeteer offre les meilleures performances. Cependant, les tests ne sont pas l'objectif principal de Puppeteer. Il est largement utilisé pour les robots d'indexation web. Notre projet a commencé avec Puppeteer, le framework de test E2E officiel recommandé par ANTD, et après l'avoir utilisé pendant un certain temps, nous avons constaté que Puppeteer n'était pas si convivial pour les développeurs non frontaux et qu'il était difficile d'impliquer d'autres utilisateurs. Lorsque les utilisateurs écrivent des cas de test, l'absence de localisation intelligente des éléments rend la courbe d'apprentissage très élevée.

TestCafe est étonnamment facile à installer, il dispose d'un mécanisme d'attente intégré de sorte que les utilisateurs n'ont pas à attendre activement les interactions de page, et il prend en charge les tests multi-navigateurs simultanés, ce qui est utile pour les tests de compatibilité multi-navigateurs. L'inconvénient est que son processus de débogage n'est pas si convivial, et vous devez exécuter un nouveau cas d'utilisation après chaque modification de cas de test. Pour les développeurs, ils doivent avoir une certaine connaissance de la syntaxe Javascript. Deuxièmement, sa vitesse d'exécution est relativement lente par rapport à plusieurs autres frameworks, en particulier lors de l'exécution de withText() pour trouver des éléments.

Après une comparaison approfondie, nous avons finalement choisi Cypress comme notre framework E2E frontal, en énumérant quatre raisons principales :

  1. Syntaxe simple

La syntaxe utilisée dans les tests Cypress est très simple et facile à lire et à écrire. Avec un peu de pratique, vous pouvez maîtriser la création de cas de test, ce qui est important pour les projets open source car cela permet à la communauté intéressée par les cas de test E2E de participer à l'écriture de cas de test avec un coût d'apprentissage minimal.

  1. Débogage facile

Lors du débogage des cas de test, nous pouvons utiliser le Test Runner de Cypress, qui présente des données multidimensionnelles nous permettant de localiser rapidement le problème.

  • Affichage de l'état de l'exécution du cas de test, y compris le nombre de succès, d'échecs et d'exécutions en cours.
  • Affichage du temps total passé sur l'exécution de l'ensemble des tests.
  • Un Selector Playground intégré pour aider à localiser les éléments.
  • montre chaque étape d'exécution pour chaque cas d'utilisation et forme un instantané qui peut montrer des informations sur chaque étape d'exécution une fois terminée.
  1. Communauté active

Cypress dispose d'une grande communauté d'utilisateurs, et il y a toujours de nombreuses personnes dans la communauté qui partagent leurs expériences et leurs idées.

Cela est utile lorsque vous rencontrez des problèmes, et il est probable que vous rencontriez des problèmes que d'autres ont déjà rencontrés. De plus, lorsque de nouvelles fonctionnalités sont demandées, nous pouvons participer à la communauté en discutant et en ajoutant des fonctionnalités à Cypress que nous souhaitons ajouter, tout comme nous le faisons dans la communauté APISIX : écouter la communauté et lui faire des retours.

  1. Documentation claire

La structure de la documentation de Cypress est plus claire et plus complète. Dans les premières étapes d'utilisation, nous avons pu intégrer rapidement Cypress dans notre projet et écrire notre premier cas en nous basant sur les directives de la documentation officielle. De plus, il existe une grande quantité de documentation disponible sur le site de documentation qui donne aux utilisateurs de bonnes directives sur les meilleures pratiques.

Cypress et APISIX Dashboard

Il y a actuellement 49 cas de test écrits pour le tableau de bord APISIX. Nous avons configuré le CI correspondant dans GitHub Action pour nous assurer que le code passe avant chaque fusion afin de garantir la qualité du code. Nous partageons l'utilisation de Cypress dans APISIX Dashboard avec vous en nous référant aux meilleures pratiques de Cypress et en les combinant avec notre projet.

image

  1. Les fonctions couramment utilisées sont encapsulées dans des commandes.

Prenons l'exemple de la connexion, la connexion est une partie essentielle pour entrer dans le système, nous l'avons donc encapsulée dans une commande, de sorte que la commande de connexion puisse être appelée avant chaque exécution de cas.

Cypress.Commands.add("login", () => {
  cy.request(
    "POST",
    'http://127.0.0.1/apisix/admin/user/login',
    {
      username: "user",
      password: "user",
    }
  ).then((res) => {
    expect(res.body.code).to.equal(0);
    localStorage.setItem("token", res.body.data.token);
  });
});

beforeEach(() => {
   // init login
   cy.login();
})
  1. Extraire le sélecteur et les données en tant que variables publiques.

Pour rendre le code de test plus intuitif pour l'utilisateur, nous extrayons le sélecteur et les données en tant que variables publiques.

  const data = {
    name: 'hmc-auth',
    deleteSuccess: 'Delete Plugin Successfully',
  };
  const domSelector = {
    tableCell: '.ant-table-cell',
    empty: '.ant-empty-normal',
    refresh: '.anticon-reload',
    codemirror: '.CodeMirror',
    switch: '#disable',
    deleteBtn: '.ant-btn-dangerous',
  };
  1. Supprimer cy.wait(someTime)

Nous avons utilisé cy.wait(someTime) au début de Cypress, mais nous avons constaté que cy.wait(someTime) dépend trop de l'environnement réseau et des performances de la machine de test, ce qui peut entraîner des erreurs de cas de test lorsque l'environnement réseau ou les performances de la machine sont médiocres. La pratique recommandée est de l'utiliser en conjonction avec cy.intercept() pour spécifier explicitement les ressources réseau à attendre.

cy.intercept("https://apisix.apache.org/").as("fetchURL");
cy.wait("@fetchURL");

Résumé

Actuellement, APISIX Dashboard a écrit 49 cas de test. À l'avenir, nous continuerons à améliorer la couverture E2E frontale, et nous demanderons à la communauté de convenir d'écrire des cas de test pour chaque nouvelle fonctionnalité ou correction de bug soumise afin de garantir la stabilité du produit.

Bienvenue à nous rejoindre pour perfectionner le produit de passerelle de classe mondiale.

Adresse du projet : https://github.com/apache/apisix-dashboard

Tags:
APISIX Basics
Testing
Plugin