技術

Device FarmでWebアプリのテストをしてみた

AWSのDevice Farmを使ってみました。少しクセのあるサービスだと思います。動くようになるまで少し苦戦したので、まとめてみます。

Device Farmを使ってみようかどうか迷っている、これから使ってみるという方のためになればと思います。

使ってみた雑感

使ってみた個人的な感想は、「便利! でも導入が大変…」です。

Device Farmは動くようになれば、便利です。ただ動くようになるまでが少し大変ですし、動いたら動いたでメンテコストもそれなりにあります。導入の検討には、解決したい課題がこの辺りのコストを払ってでも実現したいことなのかどうか見極める必要がありそうです。

Device Farmがリリースされたのは、だいぶ昔だと思いますが、認知がいまいちなのはこの辺が原因なのかもしれません。

今回は私がDevice Farm初体験だったということもあり、興味でいろいろとやってみることができました。ただ、もうあまりやりたくないかなというのが正直なところです。

Device Farmは、最初の1000時間は無料でお試しで使用できます。私は導入時にCIとかで苦戦して、テストを相当回しましたが、それでもまだ無料枠が何百時間も残っています。この無料枠、気軽に試せるのでいいと思いました。

Device Farmとは

AWSのサービスの一つで、AWS上にあるスマフォやタブレットの実機が使えるサービスです。

実機が使えるといっても手元に物理デバイスがあるわけではないので、日常用途に使えるわけではありません。Device Farmは、アプリやサービスをリリースするときに、テストとして使用するサービスです。

Device Farmでできること

リモートでスマフォやタブレットの実機でE2Eテストができます。

スマフォやタブレットの動作確認やUI確認は、会社にある実機でやることが多いと思います。しかしこれは実機を使うので会社に行かないとできないことがほとんどです。リモートが当たり前となった今の世の流れに反します。またスマフォやタブレットのデバイスのライフサイクルは短いので、頻繁に買い換えないといけません。何より手動や半手動でやるので人的コストがかかります。

Device FarmはAWS上にある実機を使うので、これらの問題が解決します。

Device Farmでできないこと

リモートのデバイスでできることは、アプリとテストを送り込んで動かすことだけです。好きにセットアップして自由に動かせるわけではありません。

なので使えるのはデフォルトでインストールされているアプリと、自分が送り込むアプリだけです。例えば、iPhoneにChromeをインストールして動かしたりとかは、できません。デバイス自体は手動で動かすことができるのですが、初期設定のままという制約がありそうです。Device Farmは、テストを送り込んでそれを動かすのが前提のサービスと言えます。

実装

今回私がやったのは、Webアプリ(サービス)の動作テストです。Webアプリ動かすテストを作成して、Devie Farmに送り込み、Device Farm上の実機のブラウザで動かしてみました。

言語やテストコードの違いはありますが、以下のサイトに近い事をやっています。
https://dev.classmethod.jp/articles/appium-android-web-browser/

Device Farmがカバーしているテストフレームワークは、AppiumとCalabashです。言語は、Appiumなら、Java, Python, Node.js, Rubyが使えます。

私は、PythonとAppiumでやりました。AppiumもCalabashどちらも使ったことがなかったのですが、Appiumのほうが主流っぽいのと、Seleniumはけっこう使っていたので、すぐに使えるようになるだろうと思ってAppiumにしました。言語は、Javaは何年も触っていないのと環境構築が面倒、Rubyは触ったことない、生JSではあまりやりたくないという理由でPythonです。

必要な前提知識

今回の技術でやってみて、私は前提知識として以下のものが必要だと感じました。

  • Pythonの基本
  • SeleniumとWebアプリの基本動作
  • CI

書くのはテストなので、プログラミングに精通している必要はありませんが、それでも最低限の知識は必要です。

それよりSeleniumとWebアプリの基本は知っていないと厳しいと思います。AppiumはSeleniumをスマフォでも動くようにしたものです。基本は同じです。なのでエレメントを取得してアクションをするというSeleniumの基本的な流れは知っておいた方がいいでしょう。また、Webアプリの操作なので、セッション、トークン、クッキーなどは知っておく必要があります。

CIについても多少は知っておいた方がいいです。Device Farmがクセがあるのは、特にCI周りです。CIの基本を知っていないと、作成したテストの自動デプロイに苦戦するかもしれません。

環境構築

Python周り

環境構築もかなりクセがあります。公式にはPythonのバージョンは3.7とあります。Pythonの3.8以上からサポートされている便利な記法は使えません。試しに、3.9で試みたのですが、案の定動作しませんでした。

あと公式では、virtualenvで仮想環境を作る手順を推奨しています。理由は余計なライブラリが入らないからとなっていたので、じゃあAnacondaでもいいかと思って、私は最初Anacondaの仮想環境でやりました。デプロイして何でか動かないなーと思っていたら、Anacondaに組み込まれていたライブラリが原因でした。この辺は直接エラーメッセージを調べていっても、原因に直結しなかったので、解決まで苦労した記憶があります。

Device Farmの実行環境はかなりシビアです。「できるだけシンプル環境、可能な限りマニュアル通り」を心がける必要があります。

Appium周り

Appiumのセットアップは最初、公式を見てやっていたのですが、appium-doctorなどが無くて、ちょっと不親切です。Appiumをセットアップしてみた系のサイトはいくつかヒットしますが、私はこのサイトが役に立つと思いました。https://qiita.com/ayaka105/items/c77c76df488f0ecfd099

私はネイティブアプリは開発したことがなかったので、この辺の環境は一からのセットアップが必要でした。特に苦労はしませんでしたが、時間がかかりました。XCodeが15GBぐらい(? 正確なサイズは忘れた…)あって、かなり時間がかかりました。フリーズしてるんじゃないかと思ったぐらいです^^;

Android関連は以下のサイトを参考にしました。 https://qiita.com/emurin/items/5cb9632514a74b056217

テスト作成

テストの実装部分に関してはAppiumの内容であり、Device Farmとはあまり関係ないので、今回は詳細は書きませんが、これも少しクセがあるなと思いました。Seleniumよりとっつきづらいです。

Appiumは以下の様にchromedriverの自動更新オプションを付けて起動しておかないと、Android系のテストが動かなかったです。

appium --allow-insecure chromedriver_autodownload

Appiumには関数が無いことがあってseleniumからimportしないといけなかったり、ネイティブアプリ用の関数なのかWebブラウザ用の関数なのかがわかりづらく少しごちゃごちゃしています。

Androidでは動くけどiOSでは動かない、もしくはその逆という事象も頻発します。Caps(デバイスの設定値のようなもの)をいろいろ設定したり、苦肉の策としてXPATHでエレメントを指定したりして、汎用性のないコードになりがちです。メンテコストが結構あるなと感じました。

また最終的には、ローカルでは動くけど、Device Farmでは動かないということがありました。この辺はアプリによって原因が違うので試行錯誤するしかなさそうです。スクロール入れたりwait処理をいれたりして、try&errorって感じです。

screen shotが最新のiOSでとれないことがありました。これは最新のAppiumではサポート済みなのですが、Device Farmが最新のAppiumをサポートしていないようで、解決作が見つかりませんでした。なので、最新iOSのスクリーンキャプチャは取らないようにテストを修正しました。

Device Farmのテストは、ネット上にサンプルが少ないのが辛いところです。Appiumの公式サンプルを見ながら作成して、Device Farmにデプロイ後はエラーを1コずつ潰してくという方法しかなさそうです。Python×Appium×Device FarmのサンプルはAWS公式で以下があるのですが、もう全然メンテされていません。最終更新は2016年でissueも放置されています。
https://github.com/aws-samples/aws-device-farm-appium-python-tests-for-android-sample-app

こちら、試しに動かして見たのですが、やはり動きませんでした。エラー内容的に、__init__.pyを全部削除すれば動きそうな気はしますが、試していません。

CI(デプロイ)

なんとかDevice Farmで動くテストが作れたら、最後はCIです。

CodePipelineがDevice Farmをサポートしているので、最初CodePipelineを試みたのですが、failしてdeployできません。エラーメッセージを見ても具体的な内容ではなかったので、よくわかりませんでした。AWSサポートに問い合わせできる環境ではあったのですが、問い合わせするのも何か面倒くさいなと思って、躊躇していました。

手動deploy自体は、AWS公式にあります。
https://docs.aws.amazon.com/ja_jp/devicefarm/latest/developerguide/test-types-appium.html

これと同じことができればいいだけなので、CodeBuild×AWS CLIでゴリ押しできないかなと思ったら、同じようなことをやっている人がいました。
https://qiita.com/yousan/items/a5b4f59c234e83b1cbad

最終的にはこちらを参考にして、CodeBuildのみでdeployするようにしました。

まとめ

以上、Device Farmを導入してみたという記事でした。

Device Farmは流行っていないのか、AWSの提供機能が微妙で、参考記事も少なめです。導入や運用には苦労しそうという印象です。

私はPythonでやったのですが、Device FarmやAppiumのメインサポートはJavaっぽいので、Javaでやったほうが良かったかもと思いました。