Amazon Device Farmに関して、実際に色々触ってみての感想。 既存のinstrumentsのテストやEspressoを実施、はたまたAPI経由で操作した時の感想です。(APIはできる、ところまで確認したというのが正しいですが。時間あったらAPIは試す。) 即時性の求められるテスト実行には少し向かないけれど、案外段階かもしれない。 Androidのinstrumentsによるテストの実施 JUni4の記述を自動でテスト対象と認識させるには以下が必要。JUnit4ベースになって test の接頭辞をつけなくなって良かったのだけれど、ここに来て必要になるとは… テストクラス名に*Testと、Testの接尾辞をつける テストクラス内のテストケース名にtest*と接頭辞をつける 他は特に問題なさそう。 @RunWith(Theories.class) と @DataPoints におけるパラメータ化テストだったり、 @Before/@Afterはともにできました。また、Espressoのテストも無事実施することができました。 この28件の成功の中には、EspressoやParametarized Testも含まれている状態です。 参考: https://github.com/awslabs/aws-device-farm-sample-app-for-android/issues/5 https://forums.aws.amazon.com/thread.jspa?threadID=211353&tstart=0&messageID=669228#669228 アップデートするAPKの生成 $ ./gradlew assembleDebug $ ./gradlew assembleDebugAndroidTest APIによるアップデート、テスト実施の自動化 AmazonのRubyライブラリにすでに統合されていた。 https://github.com/aws/aws-sdk-ruby なので、特に問題なくテスト対象のapkをアップロード、instrumentsのテストを実施、結果を得るという一連の流れをRubyスクリプトでサクッと実現できそうでした。 ドキュメントはこちら。中身見ると、JSONで設定ファイル作れば十分な感じがしますね。 http://docs.aws.amazon.com/sdkforruby/api/Aws/DeviceFarm/Client.html 重要なところは、 #create_upload(options = {}) ここで、テストのconfiguration設定時には type: に INSTRUMENTATION_TEST_PACKAGE を指定する #schedule_run(options = {}) 実際にテストを実施する ほか、いくつか端末の設定も含まれているのでいくつか通信が必要そう。 締め 色々段階っぽいですが、現状の結論としては以下ぽい。 (私のコメント箇所は、最終的にクラス名にTest加えたり、テスト対象だけtestつけるとかしたら解決できました。) @Kazu_cocoa 手元でも動かせるテストをリモートでも自然に動かせるみたいのじゃないとテスト書くのやってらんないし、現状特定用途向けにしか使えなそうっすねえ。デベロップメントテスト走らせるには厳しい —…More
Tag Archives: android
AndroidTestingSupportLibrary22.2.1リリースメモ
2015年9月14日に、新しいAndroid Testing Support Libraryがリリースされていました。Android Test KitのEspressoなどのバージョンがあがってたのでざっと調べたに続いて、少し見てみようと思います。 releasenoteなんかはgithub.ioで公開されるようになったのですね。 https://google.github.io/android-testing-support-library/downloads/release-notes/index.html リポジトリはこちら https://github.com/google/android-testing-support-library/tree/gh-pages 主な内容 espresso 各種修正 rule IntentTestRule の追加 runner JaCoCo supportの修正 test shardingの修正 他、API 23に向けた修正 External contributionという枠があったのですが、外部からの修正に関しても明記するようになったのですかね。貢献へのモチベーション上がりそうな感じですね 🙂 One More Things GitHubにAccessibilityの確認用ライブラリが公開されていました。Espressoの、Accessibilityの部分ぽいです。 https://github.com/google/Accessibility-Test-Framework-for-Android/blob/master/src/main/java/com/google/android/apps/common/testing/accessibility/framework/integrations/espresso/AccessibilityValidator.javaMore
Stetho1.2.0でScreenchastingが実現されている
Stetho1.2.0がリリースされていたので、私向けのメモ含めて。 Changelogはこちら New Chromeへのscreencasting initalizeするのが楽になった 他にも、SQLに対してEXPLAINできるようになったり。ElementタブからCTRL+Fして要素を検索できるようになったり。 initalizeが楽になった 今まで、複数行を使って Stetho.initialize に与えていたものが、1行に済むように。例えば以下。 Screencasting ChromeDevToolsの機能を使って、AndroidのViewをChrome上に表示させる、という機能です。(ChromeDevTools自体、こういう機能あったのですね。この機能を知るまで、全く知らなかったです…)それがStethoに統合されました。 統合するPR ただ、以下だとキーボードが表示されているのですが、Viewを取得するだけなのでシステム側のViewを持ってくることができません。なら、システムダイアログなんかは取ってこれなさそう。 少しコード見てみると、確かに activity からViewを取ってきているので、そうっぽい。 https://github.com/facebook/stetho/pull/190/files#diff-ac2bcff06c8c53f332d091e75117b95cR87 たとえば、ここの機能だけをみると単純にAndroidアプリをブラウザ上から操作する場合は以下のようなサービスが存在します。 http://www.vysor.io/ http://openstf.io/ これらと比べて技術的にChromeDevToolsを使ってStethoはどうようなことを実現されているぶん、実現も容易になっていそうです。このコードの変更箇所を少し覗いてみましたが、思いの外少ない実装で実現されているのですね…STFはもっとチューニングしてそうなので、ちょっと毛並みが違いそうですが。 https://github.com/facebook/stetho/pull/190 締め Screencast自体、いろいろ楽に類似サービスみたいなやつ構築できるようになりそうですね。サービスではなく、内々で使うには十分な感じものもが。時代はChromeDevToolsかなー。More
Android Test KitのEspressoなどのバージョンがあがってたのでざっと調べた
ちょっと追えていなかったのですがEspresso関連のライブラリが2.1が2015年4月21日に、2.2が2015年5月28日にリリースされたのですね。 ちょっと順に追ってみます。 android-test-kit release note 内容としては、2.0=>2.1では破壊的な変更が発生したので移行時には注意しましょう、でしょうか。ただ、 ActivityInstrumentationTestCase2 を脱却して、 @Rule ベースでアクティビティの起動/終了が管理されるようになったので、個人的には移行をためらう理由もなく、という感じですね。 そのほか、intentなんかも含め、JUnit4らしく?Ruleベースのテストの周辺環境記述に移り変わってきた感じがします。 from 2.0 to 2.1 com.android.support.test:testing-support-lib:0.1 が com.android.support.test:runner:0.2 と com.android.support.test:rules:0.2 に分割された Gradleプロジェクトを書き換えると思うのですが、書き換えた後はGradleのキャッシュを飛ばしてあげましょう。依存関係に不整合が生じるときがあります。 espressoに以下の新機能が追加されました espresso-intents ActivityTestRule を拡張した IntentsTestRule として、functional UI Testとしてインテントを使えるルールが提供されるようになったらしい espresso-core ViewActions なんかの機能追加 CheatSheetも更新されてました rules ActivityTestRule が追加されたことで、 single activityのテストを実施するときにわざわざ ActivityInstrumentationTestCase2 を継承する必要がなくなりました UiThreadRuleやUiThreadTest、ServiceTestRuleのRuleが追加されたので、これもRuleベースでテストをかけそう いい感じですね!! UIAutomator UiDevice#dumpWindowHierarchy() の機能追加 コード書き換え ActivityTestRuleが追加されたことで、いままで致し方なく継承していた ActivityInstrumentationTestCase2 から脱却します。 ActivityInstrumentationTestCase2 ベース ActivityTestRule ベース 大分すっきりしました。Activityの起動と破棄が…More
Android端末の特定パッケージが使う資源を可視化する単純なライブラリを作った
AndroidのCPUリソースやメモリリソースを可視化するために、以下のような簡単なライブラリを作りました。 すみません。Java系ではなくRubyスクリプトです。 https://github.com/KazuCocoa/droid-monitor 単に、 cpuinfoやmeminfoを整形してjsonファイルとして書き出す Google APIを使ってグラフ化する形式にファイルを整形する 簡単なテンプレートHTMLを生成する ということだけを行っている小さなものです。こういう可視化するツール、手軽に使えるものがなかったので用意してみました。以外と開発者はここらへん気にしないのですかね?? adbコマンドの dumpsys を使うので、Androidのバージョン関わらず値を取得することができます。meminfo に関しては、API Level 18を境に取得可能な形式が変わっているので、ライブラリ側でAPIバージョンを見て対応フォーマットを判断してます。 以下のような感じ。 CPU Memory 使い方 https://github.com/KazuCocoa/droid-monitor/tree/master/sample に2種類用意したのでそれを見るのが早そう。 こういうときに使う 例えば、Appiumなどを使って常に同じシナリオで、開発周期ごとのリリース物のCPU使用率を計測します。それにより、突然資源の使い方が激しくなったときを検出しやすくします。 あと、adbコマンドを使うだけなので、初期化時の引数にadb devicesなどで得られる端末のシリアル番号を指定してあげると、特定の端末のみをターゲットにすることができます。 締め adbコマンド、いろいろあって便利。モニタリング用のAPKアプリを作って常駐させておくのも良いのですが、adbコマンドがいろいろ便利なので計測対象の端末に何も手を加えずに資源を可視化できるほうがお得感ありますね。More
Stetho1.1.1でTimberを経由したconsoleへの出力が可能になってた
ふとStethoを見てみると、以下の通り1.1.1がリリースされていました。 ここでは、bug fixとstetho-timberが追加された模様。 https://github.com/facebook/stetho/releases/tag/v1.1.1 stetho-timber 自体、okhttpやhttpconnetionのようにpluginとして実装されてます。 なので、build.gradleにtimber向けの行を追加する必要があります。 SetUp stetho-timber add dependencies build.gradle Plant StethoTree on Timber Example… ここでなくても、 onCreate に Timber.plant(new StethoTree()); を加えてあげるだけで良いです。 ここはTimberと同じですね。 Build… and see Google Dev Console 地味に、同じlog文字列に対しては行を折りたたんでカウントしてくれるのが優しいですねMore
Replacing ActionBarActivity to AppCompatActivity
The following article was mentioned that ActionBarActivity is dead and you should use AppCompatActivity. https://plus.google.com/+AndroidDevelopers/posts/LNyDnnBYJ8r So, I tried to change my private application from ActionBarActivity to AppCompatActivity. In usually, it is enough to replace extend ActionBarActivity to extend AppCompatActivity. But I enchanted a issue regarding theme. In ActionBarActivity case, I use the following theme as…More
Stetho and PonyDebugger support finding elements
You know for finding elements is the first step to describe GUI Testing scenarios. For example, you need to find accessibilityIdentifier, accessibilityLabel, text and so on to describe GUI test in iOS with UIAutomation or Appium. In Android, you need to detect contentDescription or text and so on. In usually, anyone use Appium Inspector or…More
Androidのhierarchy viewerをStetho使ってChromeで見られるようになった
Stethoが1.1.0に更新され、CHANGELOGも更新されました。 大きな機能追加としては、hierarchy viewerの追加でしょうか。今までだと、 uiautomatorviewer を単品で使うかAndroid Device Monitorを使う必要があるため、確認が少し面倒でした。 これにより、Chromeブラウザがあれば同様の機能を見ることができます。API Level18以上だと、選択した箇所がハイライトもされます。 個人的には、これでAppiumのシナリオ書くときなんかも、Chrome見れば十分、というのが良いですね。Androidの開発環境が十分でないときでも、シナリオを増強できる。ちなみに、これ有効にしていると、Chromeでviewを読み込むための時間が必要になるのでアプリの動作が若干緩慢になりました。 XPathをコピーすると //*[@id=”@id/example_path”] のような値が取得できるのですが、これはXPath strategyでは正しく識別できない。このidはresource_idなので、 //*[@resource-id=”packagename:id/example_path”] のように指定する必要がありますね。 example_pathちょっとコードを追ってみる。 対象バージョン Stetho 1.1.0 Stethoの開発に使っている依存関係。 なるほど。junit4.12使っているのか。 https://github.com/facebook/stetho/blob/master/stetho/build.gradle#L18 Stetho.java https://github.com/facebook/stetho/blob/master/stetho/src/main/java/com/facebook/stetho/Stetho.java デフォルトで読み込まれるPluginの中は以下で追加している。HprofDumperPluginとCrashDumperPluginは今回の更新で入ったものかな。このようにplugins.addで、このほかにも独自Pluginを導入する方法もreadmeに書かれている。 以下は、Chromeのinspectorで表示するためのものを読み込んでいるっぽい。 なるほど。 全体的に軽く眺めただけなのですが、まだ経験の浅い私からすると色々参考になる。アノテーションの使い方とかも。 あと、Stetho、使いやすいので不具合あったときは積極的にコミットしていきたい。More
DroidDriverのJavaDocを少し観察してみた
DroidDriverのJavaDocをもすこし読んでみた。 io.appium.droiddriverのJavaDocsより 以下、いくつかピックアップして読んでみた。 BaseDroidDriver DroidDriverを使ってテストを記述するとき、通常は BaseDroidDriverTest を継承して使う。 BaseDroidDriverTest は、 D2ActivityInstrumentationTestCase2 を継承している。 D2ActivityInstrumentationTestCase2 は ActivityInstrumentationTestCase2 を継承している。 D2ActivityInstrumentationTestCase2 は ActivityInstrumentationTestCase2 で既知の不具合であるISCよりも小さなバージョンのOSで再現するNullPointerExceptionの修正を含んでいるとのこと。 D2ActivityInstrumentationTestCase2 にある scrubClass の引用 Fixes a bug in ActivityTestCase.scrubClass(java.lang.Class) that causes NullPointerException if your leaf-level test class declares static fields. This is a known bug that has been fixed in ICS Android release. But it still…More