How Guru’s Engineers Use Cypress for Better Burn Testing
Besoin d'une meilleure façon de gérer les tests de résistance ? Deux de nos ingénieurs front-end ont trouvé un moyen d'utiliser Cypress pour améliorer leur gestion de l'assurance qualité.
Nous partageons tous des connaissances chez Guru, et quand nous découvrons quelque chose de nouveau et d'utile, nous voulons que le monde le sache ! Notre équipe d'ingénierie utilise Cypress dans son processus de test et d'assurance qualité. Ils ont découvert une nouvelle façon d'aider à réaliser de meilleurs tests de résistance, et ils veulent partager leur nouveau processus amélioré avec d'autres ingénieurs et testeurs.
Au cours de l'année dernière, nous nous sommes concentrés sur l'augmentation de notre couverture de test — en particulier, les tests de bout en bout qui garantissent le bon fonctionnement des différents flux de notre produit lors de mises à jour du code. Pour ce type de test, nous utilisons un outil appelé Cypress qui simule le comportement des utilisateurs avec notre application web et notre extension Google Chrome. Cette suite de tests s'exécute à chaque demande de tirage pour s'assurer que le nouveau code ne casse rien dans notre interface utilisateur. Nous voulons également bloquer les versions si notre suite Cypress échoue sur notre branche de production.
Ce que nous recherchons dans les tests traditionnels
Un problème auquel nous avons été confrontés est que certains de nos tests échouent, mais pas pour des raisons liées à l'interface utilisateur ou au code. Alors, comment Cypress nous aide-t-il dans ces cas ? Nous faisons agir Cypress comme un utilisateur dont nous pouvons définir le comportement. Il y a plusieurs variables qui pourraient amener Cypress à nous signaler un échec, mais du point de vue d'un utilisateur, rien ne semble faux.
Par exemple, il pourrait y avoir un test qui dit : « Allez à cette partie de l'application web > Ajoutez une nouvelle carte Guru > Attendez-vous à voir un état post-création ». Si l'état de chargement de la création d'une carte reste trop longtemps et que Cypress commence à chercher l'état post-création avant qu'il ne soit là, ce test pourrait échouer (la plupart du temps, cependant, ce test réussira). S'il réussit une fois lors d'une demande de tirage, nous pouvons fusionner du code qui peut parfois être instable. Mais nous ne saurons pas s'il le fait ; un test réussi ne garantit pas que le code est correct.
Ce genre de situation réduit la fiabilité de notre couverture de test. Par conséquent, lorsque des échecs de test surgissent dans notre pipeline de déploiement, nous devons vérifier s'il s'agit d'un problème avec l'interface utilisateur — ou avec le test. Pour résoudre cela, nous avons commencé à réfléchir aux moyens de détecter si un test pourrait échouer avant qu'il ne soit soumis à notre branche de code de production.
Comment les tests de résistance aident
Entrez dans les tests de résistance. Les tests de résistance sont un processus utilisé pour tester quelque chose dans des conditions plus rigoureuses ou extrêmes. On les appelle parfois aussi tests de stress ou tests de charge, selon la méthode ou le domaine spécifique testé.
Chez Guru, nous utilisons les tests de résistance comme une partie de notre suite Cypress pour tous les tests nouveaux ou modifiés qui sont ajoutés à notre code. Avant que ces tests ne puissent être fusionnés, nous les exécutons plusieurs fois de suite et tous doivent réussir pour passer à l'étape suivante de notre pipeline de construction CircleCI.
Cette étape se produit immédiatement avant que nous exécutons l'ensemble de la suite de tests Cypress. L'avantage de cet ordre est que si notre étape de test de résistance produit un échec, nous pouvons marquer l'ensemble du contrôle comme un échec tôt. Le fait de sauter le reste de la suite nous permet d'économiser du temps et de réduire le nombre de cycles nécessaires pour s'assurer que les nouveaux tests introduits sont aussi fiables et tolérants aux pannes que nous le souhaitons.
Pour trouver les fichiers que nous recherchons, nous utilisons git diff sur la branche actuelle et fournissons la sortie comme paramètre à un outil appelé cypress-repeat qui nous permet d'exécuter ces tests un nombre spécifié de fois, ajoutant effectivement le test de résistance comme étape dans notre suite de tests de bout en bout.
Le résultat
Apporter ce changement à nos plans de test a donné des résultats assez solidement positifs. Pour nous, l'ajout de tests de résistance peut réduire le temps nécessaire pour trouver des tests non fiables de jusqu'à 30 minutes. Cela améliore également le temps de réponse pour ajouter de nouvelles fonctionnalités. Étant donné que les nouveaux tests ajoutés sont maintenant exécutés en premier, ils nous permettent de vérifier la stabilité avant de continuer le reste du processus de construction.
Dans l'ensemble, notre concentration continue sur l'amélioration de l'efficacité et de la robustesse de nos processus de test renforce la confiance de toute l'équipe d'ingénierie à expédier de nouvelles fonctionnalités rapidement. Nous corrigeons les bogues plus rapidement et facilitons le travail à travers tous nos bases de code. Nous espérons que cet article aidera d'autres utilisateurs de Cypress à créer de meilleurs tests et des équipes entières à travailler plus efficacement.
Nous partageons tous des connaissances chez Guru, et quand nous découvrons quelque chose de nouveau et d'utile, nous voulons que le monde le sache ! Notre équipe d'ingénierie utilise Cypress dans son processus de test et d'assurance qualité. Ils ont découvert une nouvelle façon d'aider à réaliser de meilleurs tests de résistance, et ils veulent partager leur nouveau processus amélioré avec d'autres ingénieurs et testeurs.
Au cours de l'année dernière, nous nous sommes concentrés sur l'augmentation de notre couverture de test — en particulier, les tests de bout en bout qui garantissent le bon fonctionnement des différents flux de notre produit lors de mises à jour du code. Pour ce type de test, nous utilisons un outil appelé Cypress qui simule le comportement des utilisateurs avec notre application web et notre extension Google Chrome. Cette suite de tests s'exécute à chaque demande de tirage pour s'assurer que le nouveau code ne casse rien dans notre interface utilisateur. Nous voulons également bloquer les versions si notre suite Cypress échoue sur notre branche de production.
Ce que nous recherchons dans les tests traditionnels
Un problème auquel nous avons été confrontés est que certains de nos tests échouent, mais pas pour des raisons liées à l'interface utilisateur ou au code. Alors, comment Cypress nous aide-t-il dans ces cas ? Nous faisons agir Cypress comme un utilisateur dont nous pouvons définir le comportement. Il y a plusieurs variables qui pourraient amener Cypress à nous signaler un échec, mais du point de vue d'un utilisateur, rien ne semble faux.
Par exemple, il pourrait y avoir un test qui dit : « Allez à cette partie de l'application web > Ajoutez une nouvelle carte Guru > Attendez-vous à voir un état post-création ». Si l'état de chargement de la création d'une carte reste trop longtemps et que Cypress commence à chercher l'état post-création avant qu'il ne soit là, ce test pourrait échouer (la plupart du temps, cependant, ce test réussira). S'il réussit une fois lors d'une demande de tirage, nous pouvons fusionner du code qui peut parfois être instable. Mais nous ne saurons pas s'il le fait ; un test réussi ne garantit pas que le code est correct.
Ce genre de situation réduit la fiabilité de notre couverture de test. Par conséquent, lorsque des échecs de test surgissent dans notre pipeline de déploiement, nous devons vérifier s'il s'agit d'un problème avec l'interface utilisateur — ou avec le test. Pour résoudre cela, nous avons commencé à réfléchir aux moyens de détecter si un test pourrait échouer avant qu'il ne soit soumis à notre branche de code de production.
Comment les tests de résistance aident
Entrez dans les tests de résistance. Les tests de résistance sont un processus utilisé pour tester quelque chose dans des conditions plus rigoureuses ou extrêmes. On les appelle parfois aussi tests de stress ou tests de charge, selon la méthode ou le domaine spécifique testé.
Chez Guru, nous utilisons les tests de résistance comme une partie de notre suite Cypress pour tous les tests nouveaux ou modifiés qui sont ajoutés à notre code. Avant que ces tests ne puissent être fusionnés, nous les exécutons plusieurs fois de suite et tous doivent réussir pour passer à l'étape suivante de notre pipeline de construction CircleCI.
Cette étape se produit immédiatement avant que nous exécutons l'ensemble de la suite de tests Cypress. L'avantage de cet ordre est que si notre étape de test de résistance produit un échec, nous pouvons marquer l'ensemble du contrôle comme un échec tôt. Le fait de sauter le reste de la suite nous permet d'économiser du temps et de réduire le nombre de cycles nécessaires pour s'assurer que les nouveaux tests introduits sont aussi fiables et tolérants aux pannes que nous le souhaitons.
Pour trouver les fichiers que nous recherchons, nous utilisons git diff sur la branche actuelle et fournissons la sortie comme paramètre à un outil appelé cypress-repeat qui nous permet d'exécuter ces tests un nombre spécifié de fois, ajoutant effectivement le test de résistance comme étape dans notre suite de tests de bout en bout.
Le résultat
Apporter ce changement à nos plans de test a donné des résultats assez solidement positifs. Pour nous, l'ajout de tests de résistance peut réduire le temps nécessaire pour trouver des tests non fiables de jusqu'à 30 minutes. Cela améliore également le temps de réponse pour ajouter de nouvelles fonctionnalités. Étant donné que les nouveaux tests ajoutés sont maintenant exécutés en premier, ils nous permettent de vérifier la stabilité avant de continuer le reste du processus de construction.
Dans l'ensemble, notre concentration continue sur l'amélioration de l'efficacité et de la robustesse de nos processus de test renforce la confiance de toute l'équipe d'ingénierie à expédier de nouvelles fonctionnalités rapidement. Nous corrigeons les bogues plus rapidement et facilitons le travail à travers tous nos bases de code. Nous espérons que cet article aidera d'autres utilisateurs de Cypress à créer de meilleurs tests et des équipes entières à travailler plus efficacement.
Découvrez la puissance de la plateforme Guru de première main - faites notre visite interactive du produit
