Windows デスクトップアプリのテストは、毎月数千件のテストを並行して実行するインフラがどこにも存在しなかったため、顧客から最も多く求められてきた機能の一つでした。Web のテストは比較的容易です。ヘッドレスブラウザは Linux コンテナ内で数秒で起動し、コストはわずか数分の一セントで、テスト終了後には破棄されます。一方、Windows デスクトップのテストには同等の仕組みがありません。Windows コンテナにはグラフィカルデスクトップが含まれないため、テストごとに完全な仮想マシンが必要になります。コールドスタートの Windows VM は起動に 2〜3 分 かかり、さらに Windows UI Automation はアクティブなデスクトップセッション内でしか動作しないため、誰かがログインしている必要があります。また、マシンは実行間でインストール済みファイル、レジストリキー、ユーザープロファイル、保存されたログイン情報を保持し、各アプリはそれぞれ独自のインストーラー、管理者プロンプト、初回起動ダイアログを伴います。リモートの Windows マシンには組み込みのトレース、ログ、スクリーンショットがなく、ほとんどのテスト基盤は Linux を前提に設計されていました。
チームの解決策は、Windows マシンをスマートフォンのように扱うことでした。テストが一つのデバイスを確保し、一度だけ使い、そして破棄するという考え方です。このアーキテクチャは同社のモバイルテスト基盤から着想を得ています。Kubernetes 上のカスタムデバイススケジューラが、デバイスクレーム (Device Claim) を通じて Google Compute Engine 上の Windows VM を割り当て、テストは WebdriverIO と Appium を使ってそれを遠隔操作します。デバイスモデルには二つの拡張が必要でした。デバイスをクラスター外に置けること、そしてクレームがブラウザ用の CDP を含むデスクトップ接続アドレスを返せることです。
システムは三つの部分で構成されます。Windows VM のウォームプールを維持するコントローラー、テストコードを実行する Linux ランナーポッド、そして検証対象アプリと小型のデスクトップエージェントを動かす Windows VM 本体です。ランナーはブラウザのコンテンツには Playwright の CDP、ネイティブアプリには Appium で接続し、さらに WebRTC ストリームを通じて、人々がテストをライブで観察し、後から録画を確認できるようにします。
各 VM は使い捨てです。誰もログインせず、パッチを当てず、数週間にわたって稼働させることもなく、使用後は新しいマシンに置き換えられます。
出典: Hacker News · 要約：HeadlinesBriefing