Cypress et TestSprite : à quoi sert chacun

Le verdict d'abord

• Choisissez Cypress si vous voulez des tests qui vivent dans votre dépôt, dans un langage que votre équipe écrit au quotidien, avec une expérience de débogage difficile à égaler, et que vous avez les ressources pour les écrire et les maintenir.

• Choisissez TestSprite si votre goulet d'étranglement n'est pas d'exprimer un test, mais de décider quoi tester et de garder la suite en vie, en particulier lorsqu'une grande partie du code arrive d'un agent de codage plus vite que quiconque ne peut la relire.

• Utilisez les deux si vous avez déjà une suite Cypress qui mérite d'être conservée. Laissez-la couvrir les parcours que votre équipe a écrits délibérément, et servez-vous de la vérification par agent pour l'étendue que personne n'a le temps d'écrire.

Le compromis, honnêtement, oppose la capacité au contrôle. Cypress vous donne un contrôle total et réclame en retour l'écriture et la maintenance. Un agent vous donne l'étendue sans l'écriture, et vous demande d'accepter que vous n'avez pas rédigé chaque étape vous-même.

Face à face

Là où Cypress est vraiment le meilleur choix

Dans certains cas, se tourner vers un agent est le mauvais réflexe, et il vaut la peine de les nommer.

• Les tests au niveau des composants. Monter un composant isolément et vérifier son comportement, c'est le terrain de Cypress. Un agent qui pilote un navigateur se place au mauvais niveau pour cela.

• Les parcours déterministes et sensibles sur le plan de la sécurité. Quand la séquence exacte compte et ne doit jamais dériver, un test dont chaque étape est écrite noir sur blanc et relue est le bon instrument.

• Les tests comme spécification exécutable. Certaines équipes se servent de la suite comme de l'énoncé de référence du comportement d'une fonctionnalité. Ce document doit être écrit, pas généré.

• Vous avez déjà une suite en bonne santé. Une suite Cypress à laquelle les gens font confiance et qu'ils maintiennent est un atout. La remplacer en bloc pour consolider l'outillage est rarement un bon calcul.

Là où le modèle du framework atteint sa limite

La limite n'est pas technique, elle est arithmétique. Chaque test doit être écrit par une personne, et le nombre de personnes est fixe alors que le nombre de fonctionnalités ne l'est pas. Quand un agent de codage se met à produire des modifications plus vite que quiconque ne peut les lire, la suite décroche au moment précis où vous en avez le plus besoin.

Deux symptômes apparaissent en premier. La couverture se concentre sur les parcours qu'il était intéressant d'écrire, qui sont rarement ceux qui cassent. Et la part de maintenance dans chaque sprint grimpe peu à peu, jusqu'à ce que quelqu'un propose de supprimer les tests instables — c'est ainsi que meurent les suites.

Faire tourner les deux sans dupliquer le travail

La répartition qui fonctionne en pratique se fait selon qui a décidé que le test devait exister.

Les deux peuvent tourner depuis le même pipeline. Cypress s'exécute dans votre job de CI comme aujourd'hui. La vérification par agent peut être déclenchée par l'événement de déploiement que votre pipeline émet déjà : elle démarre quand le nouveau build est en ligne et publie ses résultats sur la pull request. Aucun des deux n'a besoin de connaître l'autre.

Si vous êtes en phase d'évaluation, testez ceci

Quels que soient les outils comparés, cassez quelque chose volontairement et regardez ce que chacun rapporte. Introduisez une vraie régression, par exemple un bouton d'enregistrement qui ne persiste plus, et vérifiez trois choses : le test échoue-t-il, l'échec nomme-t-il la divergence réelle, et la personne ou l'agent chargé de corriger pourrait-il se mettre au travail à partir de ce résultat sans reconstituer toute l'histoire. Un outil qui annonce un succès sur une exécution qui n'a jamais atteint ses assertions a échoué au seul test qui compte.

Ce que TestSprite apporte à côté de Cypress

Ce que Cypress ne peut pas vous donner, c'est une couverture qui ne coûte pas de temps d'écriture, et c'est précisément le rôle de TestSprite. Les cas sont générés à partir de vos sources et de l'application en fonctionnement, puis affinés en langage courant : l'étendue cesse ainsi de dépendre du nombre d'ingénieurs que vous pouvez y consacrer.

Deux autres différences comptent au quotidien. Les étapes sont exprimées comme des intentions : une refonte qui déplace un bouton ne fait pas passer le build au rouge. Et un échec arrive sous la forme d'une description de ce qui a été tenté, de ce qu'a fait l'application et de l'endroit où les deux ont divergé — exploitable par un agent de codage comme par une personne, le premier étant de plus en plus le destinataire pertinent.

Dans une équipe qui conserve les deux, la répartition est nette : Cypress porte les parcours que quelqu'un a délibérément spécifiés, y compris les tests de composants et tout ce dont la séquence exacte fait partie du contrat. TestSprite porte l'étendue et la vérification des modifications écrites par un agent. Les deux tournent depuis le même pipeline et aucun n'a besoin de connaître l'autre.