Tester les applications de bureau Windows est depuis longtemps l'une des fonctionnalités les plus demandées par les clients, car personne ne disposait de l'infrastructure nécessaire pour exécuter chaque mois des milliers de ces tests en parallèle. Les tests web sont relativement simples : un navigateur sans interface démarre en quelques secondes dans un conteneur Linux, coûte une fraction de centime et est supprimé à la fin du test. Pour les tests de bureau Windows, il n'existe aucun équivalent. Chaque test nécessite une machine virtuelle complète, car les conteneurs Windows ne disposent pas d'un bureau graphique. Une machine virtuelle Windows démarrée à froid met 2 à 3 minutes à s'initialiser, et quelqu'un doit être connecté, car l'automatisation de l'interface Windows ne fonctionne que dans une session de bureau active. Les machines conservent aussi entre deux exécutions les fichiers installés, les clés de registre, les profils utilisateur et les identifiants enregistrés, tandis que chaque application apporte ses propres programmes d'installation, invites d'administrateur et boîtes de dialogue de premier lancement. Les machines Windows distantes n'offrent pas de traces, de journaux ni de captures d'écran intégrés, et la plupart des infrastructures de test ont été conçues autour de Linux.
La réponse de l'équipe a été de traiter les machines Windows comme des téléphones : un appareil qu'un test réserve, utilise une fois, puis jette. L'architecture s'inspire de son infrastructure de test mobile. Un planificateur d'appareils personnalisé dans Kubernetes attribue une machine virtuelle Windows sur Google Compute Engine via une réservation d'appareil (Device Claim), et le test la contrôle à distance avec WebdriverIO et Appium. Deux extensions du modèle d'appareil ont été nécessaires : les appareils peuvent se trouver en dehors du cluster, et les réservations peuvent renvoyer des adresses de connexion au bureau, y compris le CDP pour les navigateurs.
Le système comprend trois éléments : un contrôleur qui maintient un pool préchauffé de machines virtuelles Windows, un pod d'exécution Linux qui exécute le code de test, et la machine virtuelle Windows elle-même, qui exécute l'application testée et un petit agent de bureau. Le runner se connecte via le CDP de Playwright pour le contenu des navigateurs, via Appium pour les applications natives, et via un flux WebRTC qui permet de suivre les tests en direct et de consulter les enregistrements ensuite.
Chaque machine virtuelle est jetable. Personne ne s'y connecte, ne la met à jour ni ne la laisse tourner pendant des semaines, et une machine neuve remplace chacune après usage.
Source: Hacker News · Résumé par HeadlinesBriefing