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

『リファクタリング:Rubyエディション』を読んだ

最近は積読消費週間。積読だった、リファクタリング:Rubyエディションを読んだ。 いつだったか、t_wadaさんのTDDの説明の中で紹介のあった、リファクタリングの書籍に興味を持って購入したやつです。 “エンジニア”と名がつく以上、開発に特化する人も、テストに特化する人も、リファクタリングとは1度くらいは付き合う必要があると思います。テストエンジニアだとテストツールやテストコードが主になると思いますが、製品コードを読むし、必要であれば修正することもそれなりにあるはずです。これは、そんな時の助けになると思い購入していたやつです。 コード書きながらでないとよく分からないところなんかはコード書きつつも、基礎的な考え方は多少プログラミングや設計を学ぶと至るであろうことが丁寧にまとめられている感じ。こういう書籍で、経験をまとめて腹に落とすことができるって、先人の功績を享受できる年代の美味しさですね。ありがとうございます。 Rubyだとそれらをどう行うか、Ruby固有のメソッドでどう簡単に実現するか、というところが言及されててすごく役立ちました。 個人的には暗記が得意ではないこともあり、こういったものはひたすらに暗記するのではなく、実務で必要な時に索引できるよに頭の中にある程度の索引を作っておけることを重要だと考えています。頭の中に多少なりとも索引可能な状態にしておくと、Ruby以外の言語でもこうしたいとか、考えるときに探すあてになったりもしますし。必要であったら、本を持ってコードと向き合いつつ、必要なところをピックアップして体験にも馴染ませる、という感じでしょうか。 ゲートウェイパターンとか、Web開発で肥大化に立ち向かう上では必須なやつだなーとつくづく思う最近でした。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

忘れないようにIntentのUnitTestを書いてみた

昨日の記事をちょっと手を動かしておこうと思って、IntentのUnitTestを書いてみた。ついでに、@RunWith(AndroidJUnit4.class)を有効にして。 AndroidJUnit4.classを使うにあたってエラーが出て修正したポイントは2つ。あとおまけで1つ。 injectInstrumentationによるInstrumentationへのinject これしないと、super.setUp()で落ちる InstrumentationRegistry.getInstrumentation().runOnMainSync()によるintentからのActivityの起動 これしないと、startActivityがヌルポで落ちる ContextThemeWrapperを使うことで、R.style.AppThemeをテスト時にレイアウトとして使う レイアウトを独自でカスタマイズしている場合、AppThemeが無いみたいなエラーが出てきました どうやら、ContextThemeWrapperで仮のレイアウトを使うことで回避できるもよう 今回はあくまでもintentの確認なので、まー、よしですかね UIスレッドの話しなんかも、対応を終えたあとはなるほどなーという感じ。 ちょっと記述量を減らしたく、ButterKnifeを使ってみました。おまけ程度。 内容は、 com.example.activityのアクティビティを起動する 表示されるボタンをタップして、別アクティビティ(com.example.activity.Next)を起動する という内容に対して、期待したintentが飛ぶことを確認する、というものです。 ActivityUnitTestCaseなので、その実際が描画されたりはしません。これ、Integrationレベルで確認すると、Espressoを使って描画ベースの存在確認を行いますね。 ふぅ。Intent、いろいろちゃんとしておかないと魔の巣窟になって危なそうですね。サービスが肥大化してくると特に。怖い怖い。 最近、StethoをVolleyに適用しようとしています。単純に適用しようとすると、VolleyのHttpStackを活用してOkHttpStackのようなクラスを作成し、QueueRequestにHttpStackを与えます。 なのですが、今取り組んでいるところはそのような形でさくっとできるような所ではなく、少し手惑い気味。More

Testing and Securing Android Studio Applicationsを読んだ

Testing and Securing Android Studio ApplicationsのKindle版が安かったのと米国レビューもそこそこあったので読んでみました。あと、TestingとSecuringを同時に扱っていたので、基礎的な知見もまとめられているものと期待して。 結果的には、出版日も2014年8月とそんなに古くないので、入り口的な書籍としては良いと思いました。ツールやコードの話もありますが、まだ古くて使えない、というレベルのものではないですし。 内容的には、intentに対するUnit testレベルとInstrumentationを使ったレベルでのテスト方法が、個人的には何気に参考になりました。 以下は、私の備忘録込みでつらつらと… 第1章では基本的なソフトウェアセキュリティ全般の話。 Access control Asymmetric cryptography Authentication Availability Brute force Cipher Code injection Confidentiality Crack Decryption Denial-of-service(DoS) Distributed denial-of-service(DDoS) Dictionary attack Encryption Hash function Hijack attack Hypertext Transfer Protocol Secure Integrity MD5 Man-in-the-middle attack Password Phishing Risk SHA1 Sniffing attack Spoofing attack Threat Vulnerability このうち、Threat、Vulnerabilities、risksに関してはさらに言及されていました。 Threat…More