Votre application a vingt ans. Et alors ?
On me dit souvent la même chose avant un audit : « notre produit tourne en Java 1.5, on ne pourra pas le tester automatiquement. »
Si.
Un test E2E ne lit pas votre code. Il ouvre un navigateur, clique, saisit, et vérifie ce qui s'affiche. Il ne sait pas si la page a été rendue par du Java, du PHP, du .NET WebForms, du Django ou du COBOL derrière une couche web. Il voit du HTML.
C'est la seule bonne nouvelle du sujet, et elle est plus grande qu'elle n'en a l'air. Le langage du backend est la variable qui compte le moins.
Ce qui compte vraiment
Six choses. Aucune n'a de rapport avec votre stack.
Un environnement joignable. Une URL, qui ne soit pas la production, où l'application tourne dans un état connu. Sans ça, rien n'est possible.
Des points d'accroche stables. Le test doit retrouver le bouton après une refonte du CSS. La bonne réponse, ce sont des attributs dédiés, `data-testid` ou équivalent, posés une fois par les développeurs. La deuxième meilleure, ce sont les rôles et les libellés accessibles : un bouton nommé « Valider la commande » reste trouvable même quand les classes changent.
Une authentification automatisable. Un compte de test, et de préférence un moyen de se connecter par API plutôt que par le formulaire. Se reconnecter par l'écran de login à chaque test coûte des minutes sur la suite complète.
La maîtrise des données. Deux stratégies, et il faut en choisir une. Soit chaque test crée ce dont il a besoin puis nettoie derrière lui. Soit l'environnement est remis à un état connu avant la série. Le mélange des deux produit exactement les échecs aléatoires que tout le monde attribue ensuite à l'outil.
Le contrôle du temps et du hasard. Une facture datée d'aujourd'hui, un numéro de commande aléatoire, un calcul basé sur l'heure : si le test ne peut pas figer ces valeurs, il sera vert un jour et rouge le lendemain.
L'isolation. Aucun test ne doit dépendre de ce qu'un autre a laissé derrière lui.
Voilà la liste. Elle tient en six lignes et elle ne mentionne aucun framework.
Les cas qui compliquent, et ce qu'on en fait
Les identifiants générés. Les vieux frameworks serveur produisent des `id` du genre `ctl00$ContentPlaceHolder1$gvResults$ctl03$btnEdit`. Ils changent dès qu'on déplace un composant. On ne s'accroche jamais dessus. On vise le texte, le rôle, ou la position dans une ligne de tableau identifiée par son contenu.
Deux frameworks sur la même page. Un écran en React à côté d'un écran en Angular 1, dans le même produit, c'est courant sur les logiciels qui ont vécu. Pour le navigateur c'est un seul DOM, donc pour le test aussi. Le vrai piège n'est pas le mélange, c'est que les deux moitiés n'ont pas la même façon de signaler qu'elles ont fini de charger.
Les iframes et les fenêtres tierces. Paiement, SSO, éditeurs embarqués. Les deux outils savent y entrer. Ce qui coûte, c'est que le tiers change son interface sans vous prévenir. Sur les paiements, on teste contre le bac à sable du prestataire, jamais contre le vrai.
Le rendu côté serveur en images ou en canvas. Là, il n'y a pas de DOM à interroger. Un graphique en canvas, une visionneuse de plans, un rendu Java transformé en image : le test peut vérifier que l'élément apparaît, qu'il a la bonne taille, qu'un clic à telle coordonnée déclenche la bonne action. Pour aller plus loin il faut de la comparaison visuelle, qui est un autre métier et un autre budget.
Les vraies limites
Je préfère les dire avant de signer.
L'authentification intégrée Windows, en NTLM ou Kerberos, se contourne mais coûte. Les applications lourdes qui ne sont pas des pages web sortent du périmètre. Et une application sans aucun environnement de test, où la seule instance qui existe est la production, n'est pas un problème d'outillage : c'est un problème d'infrastructure à régler d'abord.
Ce que ça veut dire pour vous
Si votre produit a quinze ou vingt ans, qu'il fait vivre l'entreprise et que personne n'ose y toucher, le langage n'est pas votre obstacle.
Vos obstacles sont les six lignes plus haut. Elles se règlent en quelques jours, pas en quelques mois, et la plupart sont du travail de vos développeurs, pas du nôtre.