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

–suppress-adb-kill-server on Appium 1.4.0

Appium1.4.0で –suppress-adb-kill-server フラグが追加されていたのですね。 このフラグをonにしておけば、Appium Serverが adb kill-server してコネクション切断するということを防ぐことができる模様。 adbコマンドって、ip-address越しでも送ることができることは広く知られていると思います。ネットワーク越しで環境を構築している場合、adbのコネクションが切れると都度接続が必要になります。また、Selenium Gridを使って実施を並列化した環境を整えていると、テスト終わるときにkill-serverされるとadbのコネクションがこぞって切れるようなので、それを防ぐのにも良いとか。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

Dagger2を使って依存性の存在する箇所をテストしてみた

Dagger2を味見してみた、Dependency Injectionに関して今更だけど学んだを経て、Dagger2を触ってみました。 簡単な、Injectionの機構を使って、依存関係のある場所をテスト時だけ異なる依存関係にしてテストを実施する、というところまで達成できました。よかったよかった。そして、ある程度理解できたので、あとは実際の実装に落とし込みながらなじませる、が必要そう。 確認した内容はごくごく簡単で、表示する文言をビルド環境によって変更するというもの。Dagger2では、injectionするために@Moduleのアノテーション、@Providerのアノテーションつけられたものに対して以下のようにModuleをセットします。そこで、 SampleTestModule のように依存関係を拡張したModuleを渡してあげれば良いだけ。 Dagger2はコンパイル時に依存性が注入されるので、コンパイルされるまでは DaggerSampleApplication_SampleApplicationComponent に警告が表示されますが、それは気にしない。 通常 依存性注入 トラブルシューティング 以下の2点、気をつける必要があった。 compileOptionの追加 Gradleプロジェクトでは以下を追加しましょう。 annotationライブラリの追加 Gradleプロジェクトでは以下を追加しましょう。 ref: http://stackoverflow.com/questions/25090570/google-auto-factory-not-annotated-with-provided その他 終わったあとに見てみたのだが、以下記事も参考になりそう。 http://www.future-processing.pl/blog/android-testing-with-espresso-2-and-dagger-2-mocking-long-running-operations/ ButterKifeとDagger2は触って感覚を覚えたので、今度はRoboGuiceかな。 testotips.ioで、依存性を持つところのテストTipsとか共有したい機運だ。More

Dagger2を味見してみた

Dependency Injectionの、Dagger1とDagger2を学んで、DIの理解を深めてみる。Tasting Dagger 2 on Androidを参考にしました。 Dagger1はGuiceに影響を受けている。特徴は以下。Compile time injection。 Multiple injection points: dependencies, being injected. Multiple bindings: dependencies, being provided. Multiple modules: a collection of bindings that implement a feature. Multiple object graphs: a collection of modules that implement a scope. Dagger2はAutoValue projectの影響を受けているらしい。 No reflection at all: graph validation, configurations and preconditions at compile time.…More

Dependency Injectionに関して今更だけど学んだ

最近、Android開発でテストを構築していくとき、Dependency Injectionは避けて通れないものだなと感じたので、DIを頭になじませるために本腰を入れて学んでみることにしました。 DIの概念や簡単な説明自体は少しWebを探せば見つかるのですが、それが頭に馴染むのには少し時間がかかった… あと、実装コードをもう少し手を動かさないとな、という感じです。 作って学ぶ Dependency Injection [Ruby][設計] Jim Weirich さんから学ぶ DI(Dependency Injection) When to use Dependency Injection Inversion of Control コンテナと Dependency Injection パターン 原書: Inversion of Control Containers and the Dependency Injection pattern objc.ioの記事から Dependency Injection, Annotations, and why Java is Better Than you Think it is Injectionの機構を組み込むとき、大きくわけて Compile Time と Runtime Annotation…More

koboldを使い画像を比較する

画像比較ツールは数多くありますが、少し前にkoboldを使ったのでそのメモです。 kobold koboldは、perceptualdiffのような画像比較をnodeで行うことができるツールです。nodeで実施できるので、npmで管理することができる点、ほかツールとの組み合わせが容易なところが良いなと思ったところです。 ImaeMagicやperceptualdiffをコマンドラインから使う、ということは前からしていましたが、Yahoo!が公開しているkoboldがいい感じにnodeで切り出していたものを少し前に見つけました。機能が限定されているために不要な処理がなく使い易いです。 このkoboldの画像比較のコアはblink-diffのようです。なので、細かな設定値に関してもblink-diffをみるように書いています。blink-diffを個別に使う、でも良いかもしれませんね。 サンプルコード 以下GitHubのREADMEの通りにやれば、ざっとできることを想像できます。 https://github.com/KazuCocoa/sampleKobold positive 全体の設定のほかに、特定ファイルだけに適用したい個別の設定を追加することができたりと、比較的自由がきく npmで管理できる blockOut オプションにより、特定の領域を比較対象外にすることができる negative png以外にも比較を行いたい場合、これではまかなえない 結果の出力が今は標準出力だけれど、欲しい形で少し整形したいな。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