iOSアプリ開発、動作確認、テストを経験されている方なら分かるとおもいます。UIを確認したいときのiOSアプリの動作確認を自動化する時、UIAutomationを使う形が多いですね。そして、その場合において、一番のボトルネックはやはり実機やSimulatorの同時起動、実施速度の制約になっていきますよね。 UIAutomationは、実機で実施するには遅延があります。また、実機ではデータをCleanにして毎回テストを回すには、それ用のdebug機能を実装しなければ不可能です。 遅延に対しては、Facebookのinstruments-without-delayを経由して、遅延の少ないSimulatorで実施するこができていました。そして、特定のディレクトリを削除して毎回Cleanな状態を確保できていました。そういうことができるiOS Simulatorの価値は高いものです。(Xcode7ではツールの制約上この機能が正常に動作しませんが、このGistによると、Simulatorのplistをinjectionすれば有効にもできるそうな。) 例えば、Appiumはこのツールを組み込んでいるので、iOS実機もそうですが、シミュレータではより早く安定したGUI Testigを実施することができます。 なのですが、Simulatorは1つのセッションしか、Mac上では起動することができません。これはSimulatorやXcodeのinstrumentsに課せられた制約になります。 そこで、最近Facebookが以下の通りその問題を解決するようなライブラリをOSSとして公開しました。 FBSimulatorControl Objective-Cにより実装されていて、複数シミュレータを起動することができるようにしているもののようです。 以下がこのOSSのAboutなのですが、このライブラリは、Private APIの DVTFoundation や CoreSimulator にリンクして、直接ごにょごにょしているらしいです。例えば、シミュレータを直接操作する simctl を操作したり。Private APIをモリモリ使っているぽいので、Xcodeの変更に対してリスクはありますが、それでもFacebook同様、巨大なアプリはこういう形のツールを使わなければ、GUI Testingでは結構な時間を持っていかれますよね… About The original use-case for FBSimulatorControl was to boot Simulators to run End-to-End tests with WebDriverAgent. As FBSimulatorControl is a Mac OS X framework, it can be linked to from inside any Mac OS Library,…More
Tag Archives: test
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
最近のモバイルアプリ向けTaaS
2015年7月10日、納豆の日のときの話になります。納豆食べてないな。。 軽いまとめ Google Cloud Test Labsの、 Out of the box, without any user-written tests, robot app crawlers know just what to look out for and will find crashes in your app for you. が他に比べて優位性を高く持っている感じ 他サービスは昔からある、テストシナリオ与えたりするとそれを実行、レポートを得られるサービス テストシナリオをメンテできる人でないと運用は難しそう 最近、GoogleやAWSから実機テストに関するツールの発表がありましたね。勢いあるなーってことで、ああいった方面の、昔からあるものなんかを並べてみました。 こういうサービス、TaaS(Test as a service)ってよく言われたりします。 Googleのサービスは未使用です。他は少なからず触りました。 海外サービス Google Cloud Test Labs URL: https://developers.google.com/cloud-test-lab/ Applify basedなサービス Android AWS Device Farm…More
koboldをRubyで実行、結果を整える簡単なラッパーkoboldyを書いた
koboldというYahoo!がOSS化した画像比較ツール(https://github.com/yahoo/kobold)をRubyを介して実行、結果をJSON形式で保存するライブラリを作成しました。 https://github.com/KazuCocoa/koboldy https://rubygems.org/gems/koboldy やっていることは以下。 koboldの設定ファイル(の一部)をファイルへ出力する 今後、ちまちまoptionを増やすかも konoldコマンドを実行する koboldがインストールされていることが必要 koboldの結果を解析して、JSON形式で整えてファイルに出力する JSでやったほうが楽だったかなーと思いつつも、Rubyのほうが楽だったので。。。More
Phoenix Frameworkを触ってみる
何かやるなら、簡単なWebアプリとかかなと思ったのと、Elixirのフレームワークを何か触ってみようかなと思い以下のPhoenixを試してみました。 私が試したのはv0.13.0です。 http://www.phoenixframework.org/v0.13.0 雛形のinstallからsetupまでは以下を見ると特に問題なくできるのでリンクだけ。 http://www.phoenixframework.org/v0.13.0/docs/up-and-running 試しに、以下の記事を参考にテストを書くまで使ってみました。 http://postd.cc/testing-a-phoenix-elixir-json-api/ 作成したリポジトリは以下。 https://github.com/KazuCocoa/hello_phoenix 実行する前にpostgresqlを以下のように用意しておく必要があります。 確認 ユーザ作成 ざっとディレクトリ構成やmigrationを試してみると、Ruby on Railsがまんま持ってこられている印象をうけました。なるほど。 まだ1日くらいしか触ってないのですが、ちょっとexersism.ioで幾つか問題解きながら頭に文法をなじませようかな。More
Appium1.4.0の変更でwaitForAppScriptでテスト開始タイミングを調整する必要があった
Appium 1.4.0から、iOSアプリのテストを行おうとした時にinstrumentsの起動、sessionの確立が成功した後に Error(“App did not have elements”)); とエラーが表示されてテストが中断することが見られるようになりました。 これは、例えばプライバシーダイアログを初回アプリインストール時に表示するような、システムダイアログが表示されるアプリで発生するようになってます。 これは、以下のコードに含まれる https://github.com/appium/appium/blob/2b0ede71d1a2f50376a2edcd15636cfa9e9b8f1e/lib/devices/ios/ios.js#L457 の !IOS.isSpringBoard(sourceObj.UIAApplication) がtrueになるため、はかれるエラーです。 これはアプリ起動直後にSpringBoardが表示されて偽陽性(false positive)を検出してしまうことを避けるために入れられました。ただ、意図してシステムダイアログが出るようなアプリだと、誤ってfalseと判断されるようになりました。 一方、アプリ起動を待つために waitForAppScript というcapabilityが用意されています。これは、独自で定義した条件にマッチするまでテストシナリオの実施を待つ、というものです。これを使うことで、先ほどの問題を回避することが可能です。 例えば、簡単な対応として waitForAppScript:true;“ としておくことで、問題となる条件分岐を通らなくなります。ここら辺をもう少し調整しておくと、柔軟にテスト開始タイミングを調整することも可能ですね。 なお、すでにissueでも報告さえていました。その時の回避策が waitForAppScript の利用です。 https://github.com/appium/appium/issues/4971More
Appium1.4.0とruby_lib7.0.0がリリースされた
Appium1.4.0がBeta外れましたね。今回は、いくつかサポートに関わる気をつけておく内容がありましたのでめもめも。 Appium https://github.com/appium/appium/releases/tag/v1.4.0 いくつかにdeprecateがつきました Node 0.10サポート iOS6.1、iOS7.0サポート(1.5でサポート切るかも) Xcode6.3未満のXcodeサポート Xcode6.0.1+iOS8.0の組み合わせは例外 他は、BugfixやAndroid向けの新しいcapabilityの追加など。 ruby_lib https://github.com/appium/ruby_lib/blob/master/release_notes.md#v700-2015-05-08 わせて7.0.0がリリースされていましたね。本体と一緒にリリースする必要があるといってたので、miniWindowがnilになるときの対応が関係しているのかな。 default waitが0になった resourceIdのバリデーションが追加された install? メソッドが app_installed?にリネームされた rubocop対応More
Snorkeling with Dagger 2でDagger2に潜った
Dagger2を味見してみたやDagger2を使って依存性の存在する箇所をテストしてみたでは、簡単な自分で作ったModuleに対して、テスト時だけ返り値を置き換える、という簡単な例を使ってDIを試してみました。 今回は、SharedPreferenceのような外部ライブラリに依存する箇所をうまく置き換え、Unit test / Integration testレベルにおけるtestabilityを向上させることを目的に追加で味わってみました。ここまでくると、大分頭の理解としては馴染んだ感があります。 元になった記事はこの Snorkeling with Dagger 2 というものです。 http://konmik.github.io/snorkeling-with-dagger-2.html 以下では、この記事を読んで、頭になじませながら備忘録として書いたもの。 @Inject や @Module をつけたメソッドから、コンパイルによって @Component つきのブリッジが生成されて @Inject のフィールドへひも付けられる流れなんかも書かれています。Dagger prefixがついているメソッドの生成、MembersInjector を持ったインスタンスの生成という流れも載っています。 @Inject と @Module、 @Providorのひも付き方は、以下の図つきで説明されていました。 @Inject アノテーションは、以下で同じ意味を持ちます。個人で試行錯誤しながら学んでいるときも、public付きでないといけないと警告もらったりしていて、なるほどという感じ。 Dagger prefixのつくメソッドは、コンパイルされなければ生成されないコードが関係します。そのため、コンパイルするまではエラーが表示され続けます。 そこに対しても言及されていて、著者がDagger2Helperを作ってそれを使ったエラー回避の方法や、reflectionを使った回避方法を書いていたりします。なるほど。 Tipsとして、injectionの方法を共有していました。 通常は MyApplication.inject(…) と書くのですが、ここは MainInjector.getComponent().inject(…) としてもかけるそうな。 他、reflectionを使わずにinjectionする方法も書いています。Dagger2Helperを使ってApplicationクラスにinjectを定義しておき、そのApplicationクラスを他クラスから@Injectで直接とってきて使うという方法。 この方法の性能面での有用性も書いていて、なるほどという感じでした。 A direct injection on a subclass takes about 0.0013 ms, a reflected injection on…More
Appium 1.4.0 betaがリリースされていた
Appiumの1.4.0 betaがリリースされていました。 https://github.com/appium/appium/releases/tag/v1.4.0-beta iOS8.3のサポートだったり、optionの追加というところが目新しそうですね。 Android capabilityとして以下が増えている。 disableAndroidWatchers dontStopAppOnReset dontStopAppOnReset がサポートされたので、シナリオの作成によっては adb install時に -S フラグつけてターゲットのパッケージをprocess killしないようにすうることができるようになるのですね。 Appium Serverへの引数としても、以下が増えている模様。 Capability Description Values –dont-stop-app-on-reset false (Android-only) When included, refrains from stopping the app before restart –debug-log-spacing false Add exaggerated spacing in logs to help with visual inspection –suppress-adb-kill-server false (Android-only) If set, prevents Appium from killing the adb…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
~ my tech diary ~ 