Test
- TouchUtilsを使ったAndroidテストでjava.lang.SecurityException:PermissionDenialが起きたときの回避方法 (30 Aug 2012 | Tags:
TouchUtilsを使ったAndroidテストでjava.lang.SecurityException:PermissionDenialが起きたときの回避方法 )TouchUtilsを使ったAndroidテストでjava.lang.SecurityException:PermissionDenialが起きたときの回避方法
以前の記事では、InstrumantetionTestCaseとTouchUtilsを使ってのUIテストについて書きました。
最近、この方法でテストを実行してjava.lang.SecurityException: Permission Denialが発生して、テストに失敗する事象に悩まされたので、 回避方法を記録しておきます。
原因
この問題が発生する正確な理由はわかっていません。
特定の端末(今回の場合、私が持っていたXperia arc android2.3.4)でのみ事象の発生が確認できました。
Xperia NX, MEDIASでは同じテストケースを実行してもこの現象は確認できませんでした。
これらの状況と、logcatで確認できたエラーログから察するに、 TouchUtilsは端末によっては利用できないよう制限されているようです。
そのため、テストケース中のボタンなどのViewのクリック動作がシミュレートできずにテストが失敗したようです。
TouchUtilsを使わずにテストする方法
以前紹介した方法では、ユーザのViewのクリック動作を以下のような方法でシミュレートしました。
Activityの取得
Viewを取得して、初期状態を確認。
ボタンのクリックをシミュレート。
performClick()を使った回避方法
上記のクリックのシミュレートに使用したTouchUtilsの代わりに、performClick()を使います。
※この場合、clickPerformは明示的にUIスレッドで実行する必要があります。
LinkLatest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
- AndroidアプリのUIテスト-InstrumentationTestCase編- (20 May 2012 | Tags:
AndroidアプリのUIテスト-InstrumentationTestCase編- )AndroidアプリのUIテスト-InstrumentationTestCase編-
複数のActivityに跨る画面遷移のテストを調べて、サンプルを作ってみました。
サンプルのAndroidプロジェクトとテストプロジェクトは以下に置きました。
サンプルAndroidアプリ uiTestSample
サンプルテスト uiTestSample-test
参考にしたのは以下のページ How do you test an Android application across multiple Activities?
※：参考ページでは、JUnit4を使っていますが、ここではJUnit3を使っているため一部違っています。
サンプルアプリの動作について
このサンプルでは、アプリの起動後の画面にボタンが表示され、そのボタンをクリックすると別画面に遷移します。
起動後の画面
ボタンクリックで遷移後の画面
テストの概要
このサンプルでは、アプリ起動後の画面のTextViewの内容を確認。ボタン1のクリックをエミュレートし、画面遷移後の画面のTextViewの内容を確認しています。
InstrumentationTestCase
InstrumentationTestCaseを継承したクラスを作成します。 getInstrumentation()を使うことで、現在有効になってるアクティビティを捕捉し、TouchUtilsでユーザ操作をエミュレートします。
テストの流れ
捕捉するインテント情報を設定
存在するInstrumentation.ActivityMonitorがヒットするまで待ちます。タイムアウト時間を設定。
Viewを取得して、初期状態を確認。
ボタンのクリックをエミュレート。
再度Activityを取得。
画面遷移後の表示を確認。
まとめ
TouchUtilsを使えば、このほかにもドラッグ、スクロール、長押し等色々エミュレートでき、UIスレッドを意識しないで書けるので、アプリのハッピーパスのテストくらいであれば簡単に書けそうです。
Latest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
- 【意訳】Play Framework 2.0とJsTestDriverによるJavaScriptテスト。 (21 Feb 2012 | Tags:
【意訳】Play Framework 2.0とJsTestDriverによるJavaScriptテスト。 )【意訳】Play Framework 2.0とJsTestDriverによるJavaScriptテスト。
Testing javascript with Play Framework 2.0 and JsTestDriverを適当翻訳でご紹介します。
元記事はこちら
qwallet.comでは、バックエンドにScala on Play2.0を使った広大なjavascriptアプリケーションを構築しています。
Scalaの開発にIntelliJ IDEAを使うようになってからは、JavaScriptでも同じように使っています。
これにより、IntelliJとJsTestDriverの統合による恩恵を受けています。
JavaScriptアプリでは、常に3つのブラウザを対象にテストをしています。
テストコンソールにはテスト結果と、ブラウザからフェッチされたコンソール出力を確認できます。
上の試験例では、FireFox, Chromeのテストは通っていますが、Safariでは失敗しています。 サンプルでは３つのテストケースがあり、拡張した1つは2つのテストメソッドを持っています。 もしエラーが発生した場合、スタックトレースがクリッカブルになり、IntelliJはエラーの行右側に飛びます。
テストはとても速いですが、この小さなサブセットのためにChromeでは6msかかっていますが、まだ改善の余地があります。
Play2.0の親切なところは、JavaScriptファイルの自動コンパイルです。 JsTestDriverのdevモードでは、ライブラリファイルとテストケースをブラウザに送り、アプリケーションファイルはPlay2.0アプリケーションによって送られます。 Playは、ファイルの変更を検知して自動でリコンパイルします。 テストを書くときに見逃しているかもしれないものをコンパイラがキャッチしてくれ、結果としてカバレッジが向上します。
CIモードでは、JavaScriptファイルは1度コンパイルされておりPlayを経由して送られる必要がない。 この方法はとても早く、Playがバックグラウンドで実行されている必要性を低減してくれます。
qwallet.comの継続的デプロイの運用では、アプリケーションの全ての部分をテストします。 JsTestDriverはクロージャーコンパイラーとバンドルされ、fast devモードユニットテストとテスティングストラテジーのコンポーネントとして提供されています。
ところで、もし興味があったら、jobs@qwalletにメールを送ってくれ。
Latest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
