サードパーティ ライブラリ (Twitter4j) を使用して Android アプリケーションを開発しています。JUnit と機能テストでこれらのオブジェクト (私が作成したオブジェクトも) をモックできるようにしたいと考えています。
いくつかのモッキング ライブラリを使用した良い経験があり、それらを推奨できますか?
サードパーティ ライブラリ (Twitter4j) を使用して Android アプリケーションを開発しています。JUnit と機能テストでこれらのオブジェクト (私が作成したオブジェクトも) をモックできるようにしたいと考えています。
いくつかのモッキング ライブラリを使用した良い経験があり、それらを推奨できますか?
(更新: Mockito はバージョン 1.9.5 の時点で Android サポートを追加し、EasyMock はバージョン 3.2 の時点で Android サポートを追加しました。実行時にコードを生成するビットを除外し、プラグイン可能にすることで、たとえば cglib の代わりに dexmaker を使用します。)
DixonD によって言及されたandroid-mock (かなり新しく、証明されていないライブラリ) を除いて、現在のところ解決策はありません。CGLib はバイトコード生成に依存しており、Dalvik では動作しないため (これも Android の一部ではない Java Beans パッケージに依存しています)、 CGLib ( Mockito、単純なEasyMock ) に基づくものはすぐに忘れることができます。
Android に付属する非常に少数のモック クラス ( MockContextなど) を使用することもできますが、それらは動作を検証せず、単なるスタブです。それらのデフォルトの動作は、すべてのメソッドで実行時エラーをスローすることであるため、それらをサブクラス化し、モックするメソッドをオーバーライドする必要があります。
ただし、インストルメンテーション以外のテスト、つまり JVM で実行される標準ユニット テストでは、モッキング ライブラリを引き続き使用できます。PowerMockを使用してフレームワーク メソッドをモックできます。これは静的メソッドとコンストラクターのモックをサポートしているため、Ruby と同じくらい強力なモックを作成できます (使用するのが面倒です)。
JUnit 4 + PowerMock + Mockito を使用し、すべての通常の JUnit テストを継承する基底クラスで Context や TextUtils などのクラスをモック化します。インストルメンテーション テストでは、カスタム モック クラスを作成し、ファクトリを使用して実行時にインスタンス化する実装 (モックかどうか) を決定します。
私は最近、Android で動作するネイティブの Scala モッキング フレームワークである Borachio をリリースしました。
Borachio は Scala で作成されているため、テストは Scala で作成する必要があります。ただし、Java で記述されたコードのテストには使用できます。
私のブログには、Android で Borachio を使用する方法の説明があります。
http://www.paulbutcher.com/2011/03/mock-objects-on-android-with-borachio-part-1/ http://www.paulbutcher.com/2011/03/mock-objects-on- android-with-borachio-part-2/ http://www.paulbutcher.com/2011/03/mock-objects-on-android-with-borachio-part-3/
Borachio はScalaMockになりました。
Robolectricは別のアプローチを使用します。DVMで実行する代わりに、Android SDKを「デファング」して、JUnit4フレームワークを使用してJVMでAndroidテストを直接実行できるようにします。テストは明らかに構築と実行がはるかに高速で、モックが少なくて済みます。
[一般的なアプローチ]は、MockitoやAndroidMockなどのモックフレームワークを使用してAndroidSDKをモックアウトすることです。これは有効なアプローチですが、Robolectricがないと、Androidアプリをテストするために必要なモックのレベルによって、アプリケーションコードの本質的に逆の実装であるテストがすぐに得られることがわかりました。
Robolectricを使用すると、ブラックボックステストに近いテストスタイルが可能になり、テストがリファクタリングに効果的になり、Androidの実装ではなくアプリケーションの動作に焦点を当てることができます。必要に応じて、Robolectricと一緒にモックフレームワークを引き続き使用できます。
仕組みは次のとおりです。
[インターセプト]Androidクラスのロードとメソッド本体の書き換え。RobolectricはAndroidメソッドを再定義して、null(または0、falseなど)を返すようにします。指定されている場合、Robolectricはメソッド呼び出しをシャドウAndroidオブジェクトに転送し、AndroidSDKの動作を提供します。
更新:easymock3.2がcglibの代替プラグインのオプションを追加したようです。
easymock 2.5.2を使用しています(注-3.Xは使用しないでください)。動作しますが、モックインターフェイスの場合のみです。
したがって、ライブラリがインターフェースを公開している場合、または依存関係をインターフェースでラップする場合は、easymockを使用できます。
easymock 3.xなどのそれ以降のeasymockバージョンは、クラスとインターフェイスの両方のバイトコード操作にandroidと互換性のないcglibを使用するのに対し、2.xはクラスのモックにのみ使用するため機能しません。
Android Mockは、よく知られている Java のモック フレームワークであるEasyMock 2.4の上に書かれています。
Lmock は Android で動作しています: github.com/vmware/lmock
Android-Mock を試してみました。これまでのところ非常にうまく機能しています。それは私の問題を解決しました(EasyMockなしでAndroidTestCaseを使用するか、EasyMockを使用しますがコンテキストは許可されていません)