Das Testen von Windows-Desktop-Anwendungen gehörte lange zu den am häufigsten gewünschten Funktionen unserer Kunden, weil niemand die Infrastruktur hatte, Tausende dieser Tests jeden Monat parallel auszuführen. Webtests sind vergleichsweise einfach: Ein Headless-Browser startet in Sekunden in einem Linux-Container, kostet einen Bruchteil eines Cents und wird nach Testende verworfen. Für Windows-Desktop-Tests gibt es kein Äquivalent. Jeder Test benötigt eine vollständige virtuelle Maschine, da Windows-Container keine grafische Desktopoberfläche bieten. Eine kalt gestartete Windows-VM braucht 2 bis 3 Minuten zum Booten, und es muss jemand angemeldet sein, denn die Windows UI Automation funktioniert nur innerhalb einer aktiven Desktopsitzung. Die Maschinen behalten außerdem installierte Dateien, Registry-Schlüssel, Benutzerprofile und gespeicherte Anmeldedaten zwischen den Durchläufen bei, während jede Anwendung eigene Installationsprogramme, Administratorabfragen und Dialoge beim ersten Start mitbringt. Entfernte Windows-Maschinen bieten keine eingebauten Traces, Logs oder Screenshots, und der Großteil der Testinfrastruktur war um Linux herum entworfen worden.
Die Antwort des Teams bestand darin, Windows-Maschinen wie Telefone zu behandeln: ein Gerät, das ein Test belegt, einmal verwendet und dann wegwirft. Die Architektur übernimmt Ideen aus der mobilen Testinfrastruktur des Unternehmens. Ein eigener Gerätescheduler in Kubernetes vergibt über einen Gerätanspruch (Device Claim) eine Windows-VM auf Google Compute Engine, und der Test steuert sie per WebdriverIO und Appium aus der Ferne. Am Gerätemodell waren zwei Erweiterungen nötig: Geräte können außerhalb des Clusters liegen, und Ansprüche können Desktop-Verbindungsadressen zurückgeben, einschließlich CDP für Browser.
Das System besteht aus drei Teilen: einem Controller, der einen vorgewärmten Pool von Windows-VMs unterhält, einem Linux-Runner-Pod, der den Testcode ausführt, und der Windows-VM selbst, auf der die getestete Anwendung und ein kleiner Desktop-Agent laufen. Der Runner verbindet sich über das CDP von Playwright für Browserinhalte, über Appium für native Anwendungen und über einen WebRTC-Stream, mit dem Personen Tests live verfolgen und Aufzeichnungen anschließend prüfen können.
Jede VM ist ein Einwegobjekt. Niemand meldet sich an, spielt Patches ein oder lässt sie wochenlang laufen; nach der Nutzung ersetzt eine frische Maschine die alte.
Quelle: Hacker News · Zusammengefasst von HeadlinesBriefing