OSSとして公開された、巨大なFacebookのiOSアプリでUIAutomationを使うために使われているツール群

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

Appium1.4.9 released

Appium1.4.9がリリースされましたね。 https://github.com/appium/appium/releases/tag/v1.4.9 iOS9とXcode7の対応が主です。 以下のPRにもある通り、iOS Simulatorにおいてinstruments-without-delayが効かなくなりました。 https://github.com/facebook/instruments-without-delay/pull/18 これで、Simulatorと実機での実行速度の差分があまりなくなりましたね…悲しい. ※ 1.4.9は依存関係の都合、正しく実行できません。 1.4.10を使いましょう。 https://github.com/appium/appium/issues/5479More

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

[Elixir]Plug.Testを使ったRequestのテスト

作業メモ。 Elixir 1.0.5 Phoenix 0.14.0 Plug.Testを使ったやつ テスト対象 テストコード Phoenixを使ったやつ http://www.phoenixframework.org/docs/introduction test_helper.exs で、test用DBのcreate、migrationを行っているのですね。 test/test_helper.exs ファイル単位とか、以下のように行単位でテストできるのですね。 タグの付与と実行 moduleへのタグ moduleへのタグ定義 実行 実行 特定のタグのみ除いたテストケースの実行 test case個別へのタグ タグの定義 実行 特定のmoduleを除いたうえで、individual_test:yupを実行する ランダムにテストを実施する これ、面白いなーと感じました。 🙂 テストの自動生成 以下のようにcontroller、modelを作成したら、テストケースも自動生成されていました。 作成したモデルに対する、基本的なテストケースの自動生成良いですね。 ざっと生成されたテストケース見てみると、moduleで作成したリソースの生成/更新などの基本的な正常系、作成失敗などのエラー系。 ちなみに、以下を実行した後だと、 phoenix.gen.html とうViewも自動生成されるので、かなりお手軽。 test/controllers/user_controller_test.exs test/models/user_test.exs HelloPhoenix.ModelCase は、 test/support/model_case.ex で実装されている。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

Appium1.4.5(1.4.6)がリリースされ、ROADMAPも追加されてた

1.4.5がリリースされましたね。 fix problem with npm shrinkwrap that caused Appium not to start だそうです。依存関係を持ったライブラリの更新が主な模様。 他、以下が追加された模様です。 iOS only: webviewConnectRetriesの追加 WebViewでコネクション貼るときにretry回数を可変にしたものぽい 他、数週間前にAppium、ROADMAPを追加していましたね。 ちょっと中身みてみました。 いくつか予想していたものがあって、そうだよね〜というものも。 DroidDriver backend integration Apple Watch support iOS 8.4 support https://github.com/appium/appium/blob/master/ROADMAP.md Non-UIAutomation iOS backend これ、Calabashとか参考にすると確かにできそうなのですが、Philosophyを曲げることになるので個人的にはお流れになってほしいような。(Appiumがカバーする領域がぶれそう) 追記(2015/06/20) Appium 1.4.5、npmリリース失敗してましたね。 Appium 1.4.6が re-publish されて実質1.4.5が使えるようになりました。More

Appium x iOSのscrollに対するworkaround

AppiumでiOSアプリに対してスクロール操作を行うとき、以下のworkaroundでうまくいったので、メモ。 Appium1.4.xで動作確認済み。 OS7.0 ~ 8.x系で確認されるOS側不具合で scrollTo やUIAutomatorの scrollToVisible を使うと、以下のようなエラーがでます。 このworkaroundとして、例えばrubyだと以下で回避可能です。 elementは、find_elementなどで取得できうelementを意味します。 ※いつからあったworkaroundだろう。自前で実装してた…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