C'est probablement la question la plus courante que je reçois des ingénieurs à propos de Verdex : "Pourquoi utiliser CDP au lieu de construire par-dessus ou simplement d'étendre Playwright ?" C'est une question tout à fait légitime : le dramaturge est exceptionnel, largement adopté et a accès au CDP vianouvelle Session CDPS (). Alors laissez-moi passer en revue le raisonnement technique.
La réponse courte : Verdex est un outil de création au moment du développement qui nécessite un contrôle approfondi et spécifique sur les contextes d'inspection DOM et d'exécution JavaScript. Playwright est un programme d'exécution de tests de temps d'exécution optimisé pour la fiabilité entre navigateurs. Il s'agit de cas d'utilisation fondamentalement différents avec des exigences architecturales différentes. Comprendre pourquoi révèle quelque chose d'intéressant sur le moment où les abstractions aident et quand elles créent des frictions.
Avant de plonger, je veux être clair : Verdex doit beaucoup au design de Playwright. La mise en œuvre de l'arborescence d'accessibilité, l'approche des mondes isolés, l'attention particulière portée au cycle de vie des éléments : ce sont tous des domaines dans lesquels j'ai étudié en profondeur la base de code de Playwright et où j'ai puisé mon inspiration.
Verdex vise la parité avec le niveau de sophistication de Playwright, en particulier autour de la génération d'arborescence d'accessibilité conforme au W3C ARIA, de la gestion robuste des cycles de vie et de la navigation des cadres et des contextes d'exécution isolés. Là où Verdex diverge, ce n'est pas dans la capacité mais dans l'architecture : il ajoute des primitives d'exploration structurelle (get_ancestors,get_siblings,get_descendants) pour la construction du sélecteur de temps de création plutôt que pour la fiabilité des tests de temps d'exécution.
La question n’est pas « que peut faire Verdex que le dramaturge ne peut pas faire ? » Il s'agit de « compte tenu de ces différents objectifs, quelle fondation est la plus logique ? »
Voici la distinction fondamentale :
| Temps d'exécution (dramaturge) | Temps de création (Verdex) |
|---|---|
| Re-résoudre les sélecteurs à chaque action | Maintenir des références stables sur plusieurs requêtes |
| Prévenir les bogues d'éléments obsolètes | Activer l'exploration DOM en plusieurs étapes |
| Uniformité entre navigateurs | Profondeur d'analyse |
| Poignées d’éléments éphémères | Mappages d'éléments persistants pendant les sessions |
Les localisateurs de Playwright se résolvent à chaque action, une brillante défense contre les bugs d'éléments obsolètes qui tourmentaient Selenium. D'après leur documentation :
"Chaque fois qu'un localisateur est utilisé pour une action, un élément DOM à jour est localisé dans la page."
Pour l’exécution des tests, c’est exactement ce qui se passe.
Pour l'analyse du temps de création, où je dois appelerget_ancestors(e3), alorsget_siblings(e3), alorsget_descendants(e3)sur un même élément, cela crée des frictions. Voici ce dont Verdex a besoin :
// Requêtes séquentielles sur le même élément lors de la création get_ancestors("e3") // Remontez de cet élément spécifique get_siblings("e3", 2) // Examinez les frères et sœurs du MÊME élément get_descendants("e3") // Explorez les enfants du MÊME élémentAvec les localisateurs, vous réinterrogez le DOM à chaque fois et obtenez potentiellement des éléments différents si la page change. Avec ElementHandles (l'option persistante de Playwright), le framework décourage activement leur utilisation et les supprime automatiquement après des actions visant à imposer une nouvelle résolution. Il s’agit d’une philosophie fondamentale et non d’une omission technique.
Différents problèmes, différentes solutions.
"Mais attendez, qu'en est-il des éléments périmés ?"
Si vous connaissez le fameux SeleniumStaleElementReferenceException, vous vous demandez peut-être : l'approche de référence persistante de Verdex ne risque-t-elle pas les mêmes problèmes ?
Non, et comprendre pourquoi révèle un aperçu architectural important.
Le problème de Selenium s'est produit lors de l'exécution :
element = driver.find_element(By.ID, "submit") # ... la page est...
[Courte citation de 8% de l'article original]