Le verdict d'abord
-
Choisissez Selenium si vous avez besoin d'un contrôle précis, d'une couverture de navigateurs ou de plateformes inhabituelle, ou si vous travaillez dans un écosystème déjà construit autour de WebDriver.
-
Choisissez TestSprite si le goulot d'étranglement consiste à décider quoi tester et à maintenir la suite en vie, en particulier quand une grande partie du code provient d'un agent de codage.
-
Utilisez les deux si vous avez une suite Selenium à laquelle vos équipes font confiance. Gardez-la, et ajoutez une vérification par agent pour l'étendue que personne n'a le temps d'écrire.
Côte à côte
| Critère | Selenium | TestSprite |
|---|---|---|
| Ce que c'est | Un standard d'automatisation de navigateur, avec des bindings dans de nombreux langages | Un agent qui planifie, exécute et trie les tests sur l'application en fonctionnement |
| Qui écrit les tests | Vos ingénieurs, en Java, Python, C#, JavaScript et d'autres langages | Générés à partir de vos sources, affinés en langage naturel |
| Contrôle sur une étape | Total. Vous spécifiez chaque interaction | Les étapes sont des intentions : vous échangez de la précision contre de la durabilité |
| Quand l'UI change | Les localisateurs cassent et quelqu'un doit les réparer | Les changements cosmétiques sont généralement absorbés |
| Couverture des navigateurs et des plateformes | La plus large du secteur, y compris les cibles anciennes | Des parcours sur navigateurs modernes, contre votre application déployée |
| Coût récurrent | Écriture et maintenance, qui augmentent avec la taille de la suite | Relecture et affinage, qui augmentent plus lentement |
| Point faible | L'étendue. Vous ne couvrez que ce que quelqu'un a écrit | Le contrôle fin d'une interaction isolée |
Là où Selenium reste la bonne réponse
Des besoins de couverture inhabituels. Navigateurs anciens, comportement spécifique d'un driver, cibles embarquées. Rien d'autre n'approche une telle portée.
Des séquences déterministes. Quand l'ordre exact des interactions fait partie du contrat et ne doit jamais dévier.
Une grid déjà en place. L'infrastructure, les compétences et les conventions accumulées pendant des années sont un actif, pas un poids hérité du passé.
Là où le modèle atteint ses limites
La limite est arithmétique. Chaque test est écrit par une personne, et le nombre de personnes est fixe alors que le nombre de fonctionnalités ne l'est pas. Deux symptômes apparaissent en premier : la couverture se concentre sur les parcours qu'il était intéressant d'écrire plutôt que sur ceux qui cassent, et la part de maintenance dans chaque sprint augmente jusqu'à ce que quelqu'un propose de supprimer les tests instables.
Ce que coûte réellement une migration
Les équipes qui décident d'abandonner Selenium sous-estiment en général une chose et en surestiment une autre.
Sous-estimé : la grid n'est pas qu'une infrastructure, c'est un ensemble d'hypothèses gravées dans chaque test. Des timeouts calibrés sur sa latence, un parallélisme calibré sur sa capacité, une gestion des captures d'écran calibrée sur son stockage. Ces hypothèses ne se transposent pas, et elles restent invisibles jusqu'à la première exécution ailleurs.
Surestimé : les tests eux-mêmes. La plupart des suites ont un noyau de vingt ou trente parcours sur lesquels les équipes s'appuient vraiment, et une longue traîne que personne n'a regardée depuis un an. Migrer le noyau prend une semaine. Décider d'abandonner la traîne, voilà ce qui prend trois réunions, et c'est en général la bonne décision.
C'est précisément pourquoi faire tourner un outil en parallèle vaut mieux que migrer. Vous découvrez quels parcours étaient réellement porteurs en observant lesquels, une fois devenus silencieux, manquent à quelqu'un.
Faire tourner les deux
Répartissez selon qui a décidé que le test devait exister. Les parcours délibérément spécifiés restent dans Selenium. La régression large, et la vérification des changements produits par un agent de codage, reviennent à l'agent. Les deux s'exécutent depuis le même pipeline sans rien savoir l'un de l'autre.
Si vous évaluez ces outils, cassez quelque chose volontairement
Introduisez une vraie régression, par exemple un bouton d'enregistrement qui ne sauvegarde plus, et regardez ce que remonte chaque outil. Trois questions : le test échoue-t-il, l'échec nomme-t-il la divergence réelle, et la personne ou l'agent chargé de corriger peut-il partir de cette sortie sans avoir à 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.
Deux voies, et le choix porte en réalité sur qui possède le pipeline. Connecter la GitHub App depuis le tableau de bord ne demande absolument aucune modification de votre dépôt, car elle réagit au déploiement que votre build émet déjà. Ajouter une étape GitHub Actions place le contrôle dans le dépôt, où il est relu comme le reste du build ; les commandes actuelles se trouvent dans le dépôt CLI.
Ce que TestSprite apporte à une équipe Selenium
Une couverture qui ne consomme pas de temps d'écriture. Les cas sont générés à partir de votre produit et affinés en langage courant : l'étendue cesse d'être limitée par le nombre d'ingénieurs que vous pouvez détacher à l'écriture de tests.
Deux autres différences se voient à l'usage quotidien. Les étapes sont des intentions plutôt que des localisateurs : une refonte qui ne change rien au fonctionnement ne fait pas passer la suite au rouge, ce qui supprime la première source de maintenance. Et un échec revient 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 aussi bien par un agent de codage que par une personne.
Votre grid et votre suite existante restent exactement telles quelles. En pratique, les parcours que personne n'avait le temps d'automatiser sont couverts, et ceux que votre équipe a délibérément écrits restent sous votre contrôle.
Selenium est-il obsolète ?
Non. C'est la couche de base d'une grande part de l'industrie, et il conserve la plus large portée de plateformes disponible. Ce qui le met sous pression, c'est la capacité disponible, pas ses capacités.
Devons-nous migrer ?
Non, et une migration intégrale est rarement un bon calcul. Ajoutez de la couverture à un autre niveau plutôt que de déplacer ce qui fonctionne déjà.
Et les tests Selenium instables ?
L'instabilité tient le plus souvent à la fragilité des localisateurs ou à des hypothèses de timing. Les étapes fondées sur l'intention éliminent une bonne part de la première cause. Aucune des deux approches ne corrige un environnement réellement instable.
TestSprite peut-il exporter du code que nous pourrions exécuter dans notre grid ?
Le code source des tests générés peut être affiché ou écrit dans un fichier. Considérez-le comme l'instantané d'un parcours, et non comme l'artefact que vous maintenez à la main.
Lequel coûte le moins cher ?
Comparez le coût total. Selenium est gratuit ; le temps d'ingénierie nécessaire pour écrire et maintenir la suite ne l'est pas. La réponse dépend presque entièrement du fait que vous disposiez ou non de cette capacité.
Contrôle contre capacité, pas ancien contre moderne.
Selenium vous donne un contrôle complet et réclame en échange de l'écriture et de la maintenance. Gardez-le pour les parcours que votre équipe a délibérément spécifiés et pour une portée de plateformes inhabituelle, et ajoutez une vérification par agent pour l'étendue que personne n'a le temps d'écrire.