Appiumのいいところ・ダメなところ。そして自動テストはAIへ

はじめに

Appiumを使い始めて数年経ちました。また、筆者がAppiumを使用した独自のテストツールを作成してからも数年が経過しました。2024年の年の瀬に、Appiumについて思っていることを書き連ねます。

最初に言っておくと、Appium は素晴らしいツールです。オープンソースソフトウェアでモバイルアプリの自動化を行いたい場合は最有力候補になるでしょう。

素晴らしいツールであることは間違いないのですが、実際に使ってみるといろいろと苦労します。

Appiumのいいところ

• 無料で開始できます
• 複数のプログラミング言語をサポートしているので、その中から好みの言語を選択できます
• コミュニティによってアクティブにメンテナンスされています
• XPathやiOS class chain selectorを利用できるので開発者に画面要素識別用のIDの埋め込みを依頼しなくてもテスト担当者だけでなんとかなります
• WebViewの要素にもアクセスできます

Appiumのダメなところ

• 総じて生産性が低いです
• 不安定です。特別なことをしていなくても操作が失敗することがあります
• ネイティブ以外のアプリ（FlutterやCompose Multiplatformなど）での利用に制約があります

（iOSのみ）

• 非常に遅いです。Appiumのセッションを開始した時に発生するビルド＆インストールで長く待たされます
• 画面全体の要素を取得するコマンドが非常に遅いです
• 画面に表示されている要素にアクセスできない場合があります
• 画面に表示されていない要素にアクセスできてしまうので取り除く必要があります

Android(appium-uiautomator2-driver)は速いし良い出来だと思います。一方、iOS(appium-xcuitest-driver)は問題が多く、まったく使えなくはないが、正直しんどい。

iOSについてはAppiumそのものというよりはAppleが提供する自動化の基盤に問題があります。Googleは自動化のサポートやパフォーマンス等の品質で頑張っている印象ですが、Appleはまったく協力的ではなく、問題を放置したままです。appium-xcuitest-driverを開発しているプロジェクトもAppleが機能を提供しないからこのissueは解決できない、という話が散見されます。

自動化の根本のところを担っているプラットフォーマーがサードパーティ製の自動化ツールのサポートに積極的ではないことが、Appiumの発展を妨げていると言っていいでしょう。

自動テストはAIベースのコンピュータービジョンにシフトする

Appiumが採用しているようなUIのDOM(Document Object Model)に依存したソリューションはプラットフォームに依存した情報が含まれます。同じAppiumでもAndroidで取得したDOM情報とiOSで取得したDOM情報はまったく異なります。AppiumはAndroidとiOSの両方に対応してはいますが、DOMが非統一なので、原則としてテストコードは統一することができません。この問題を解決（または緩和）するため、ShiratesのようなDOMの差異を吸収するマッピング層を設けることでテストコードの統一を可能にする手法がありますが、マッピング層を作成して維持するのは知識も手間も必要です。

ここ最近はFlutterやCompose Multiplatformのような新手のソリューションが台頭しつつありますが、開発者が画面要素を自動テストできるようにアプリの設定をする必要があるため、ネイティブアプリよりも自動テストのハードルが高くなります。

筆者は荒ぶるDOM要素と格闘するのは疲れたので、別のソリューションで代用できないか考え中です。プラットフォームに可能な限り依存しない方法としてはやはりコンピュータービジョンによる自動化が有力と考えます。ここ最近はAIによるコンピュータービジョンのハードルが非常に下がっており、AI-OCRも無償で精度の高いものが登場してきています。これらを活用すれば、本記事で挙げたようなAppiumの問題を解決できるのではないかと考えています。

従来手法のDOMの呪縛から解放され、ビジュアルな要素をテストの基盤に据えることで、テストコードはより直感的になるはずです。

時代はAI。
乗るしかない、このビッグウェーブに。