Android開発のデザインパターン。 パート3-ユーザーインターフェイス、テスト、AndroidMock

前の記事で、MVPとは何か、MVPを使用してアプリケーション開発プロセスを編成する方法について説明しました。 次に、Tアラームをどのように開発したかを示します。

最初に、前の記事で説明したように、プレゼンテーションとプレゼンターを作成しました。

表示する

当然のことながら、私の考えはActivityクラスの継承者、またはむしろRoboActivityです。これについて簡単に説明します。 以下は、アラーム設定の編集ウィンドウの非常に特徴的なソースです。

public class AlarmEdit extends RoboActivity implements IAlarmEdit { @InjectView(R.id.ae_et_AlarmName) EditText etName; @Inject AlarmEditPresenter presenter; @InjectView(R.id.ae_btn_Save) Button btnSave; @InjectView(R.id.ae_btn_Cancel) Button btnCancel; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.alarm_edit); presenter.onCreate(this); btnSave.setOnClickListener(this); btnCancel.setOnClickListener(this); } @Override public void onClick(View btn) { AlarmEdit.ClickSourceItem clickItem = AlarmEdit.ClickSourceItem.CANCEL; switch (btn.getId()) { case R.id.ae_btn_Save: clickItem = AlarmEdit.ClickSourceItem.SAVE; break; case R.id.ae_btn_Cancel: clickItem = AlarmEdit.ClickSourceItem.CANCEL; break; } presenter.onClick(clickItem); } @Override public String getAlarmName() { return etName.getText().toString(); } @Override public void setAlarmName(String alarmName) { etName.setText(alarmName); } @Override public Bundle getViewBundle() { return getIntent().getExtras(); } } 

そこで、この例を検討し始めます。
まず、RoboActivityとは何か、なぜここで必要なのか。 RoboActivityはRoboGuiceの一部です。 RoboGuiceは、Android用の依存性注入フレームワークです。
RoboGuiceの詳細については、プロジェクトのWebサイトをご覧ください。
code.google.com/p/roboguice/wiki/SimpleExample?tm=6

このクラスでは、RoboGuiceを使用して、onCreateメソッドの退屈さを回避しています。

 etName = (EditText) findViewById(R.id.ae_et_AlarmName); 

RoboGuiceは、アクティビティを作成し、 Injectタグを使用して文字列を処理するときにすべてを行います...

 @InjectView(R.id.ae_et_AlarmName) EditText etName; 

次のようにリソースに名前を付けます。
<略 アクティビティ名> _ <abbr。 コントロールタイプの名前> _ <コントロールの名前>
アプリケーション全体から単一の「R.id」名前空間に積み上げられた大量のリソース識別子間を簡単に移動できます。

また、RoboGuiceを使用して、次の宣言を通じてプレゼンターを作成します。

 @Inject AlarmEditPresenter presenter; 

実際、RoboGuiceには、あとで紹介するいくつかの用途があります。

したがって、onCreate（）メソッドの実行時に、クラス内のすべてのフィールドはすでに初期化されており、個別に初期化を行う必要はありません。コードはきれいに見えます。

onCreate（）メソッドでは、現在のクラスをOnClickListenerとして登録し、このビュークラスへの参照をプレゼンターに渡すだけで、将来プレゼンターがビューのプロパティを制御できるようにします。 これにより、発表者のビジネスロジックがプレゼンテーションを制御するときに、制御の反転が取得されます。
これは、アプリケーションの他の部分に弱く依存している別のプレゼンタークラスに集中しているビジネスロジックをテストするために行います。 さらに、テスト中にプレゼンターをプログラム環境から切り離し、他のコンポーネントの代わりにさまざまなスタブとシミュレーションを接続し、プレゼンターでテストを実行する方法を示します。

onClick（）メソッドは、ビューがユーザーから受け取るすべてのコマンドがプレゼンターに渡されることを示します。 ここでは、ボタンの識別子をコマンドに変換するだけなので、デバッグ時にR.idクラスのリソースに対応する番号ではなくコマンドの名前が表示されます。通常、ビューからプレゼンターに何かを追加する価値はありません。

ここでは、ビューはインターフェイスを使用せずにプレゼンターと直接通信します。 プレゼンターを模倣に置き換える必要がないため、これを行いました。 単体テストではパフォーマンスをテストしません。

setAlarmName（）およびgetAlarmName（）メソッドは、プレゼンターが編集ウィンドウにアラームの名前を表示および取得するために使用します。

getViewBundle（）メソッドは、Intentを介して渡す編集可能なアラームのIDを取得するために必要です。 目覚まし時計自体は、リポジトリがロードするモデルから取得され、すべての目覚まし時計はモデルにあまりロードされないため、一度にモデルにロードされます。 モデルはプログラムの最初のアクティビティで読み込まれ、アラームのリストがあり、すべてのアラームを含むモデルがすでに必要です。
Roboguiceを使用したおかげで、Singletonモデルができました。 つまり、アプリケーション全体でモデルのインスタンスが1つあり、アクティビティからアクティビティにモデルを転送する必要はありません。 各アクティビティのプレゼンターは、R​​oboguiceからモデルを受け取ります。

 @Inject IAlarmListModel alarmListModel; 

Singletonは静的クラスではなくRoboGuiceを介して実装されているため、テストのモデルを必要なシミュレーションに置き換えることができます。

こことインターフェイスに表示されているコードは、MVPを使用して記述する必要がある追加のコードです。 プレゼンターにある残りのコードはすべて、必要なビジネスロジックが含まれているため、とにかく記述する必要があります。
言い換えれば、MVPの料金は数行のマッピングであり、これはMVPを使用した場合に得られるものとはあまり比較されていません。

インターフェイスIAlarmEdit

インターフェイスは非常に単純で、メソッドが含まれているだけなので、プレゼンターはビューと通信したり、ビューをテストのシミュレーションに置き換えたりできます。

 public interface IAlarmEdit { public enum ClickSourceItem { SAVE, CANCEL } public abstract String getAlarmName(); public abstract void setAlarmName(String alarmName); public abstract Bundle getViewBundle() } 

プレゼンターはどうですか

ユーザーインターフェイスの実装を開始し、ブレーキプログラムが好きな人はいないので、できるだけ速くしたかった。 最初は、ユーザーインターフェイスを読み込まないように、できるだけ多くのロジックをサービスに集中することを計画しました。 しかし、その後、サービスがユーザーインターフェイスと同じスレッドで実行されることを発見しました。 また、個々のスレッドを使用する場合、AsyncTaskには素晴らしい点があります。 ユーザーインターフェイスとサービスの両方で、プログラムでマルチスレッドを作成したのは彼女を通してでした。

そのため、プレゼンターにはIModelLoaderクラスのインスタンスがあります。このクラスは、リポジトリを非同期的に呼び出し、保存用のモデルを渡します。 次の記事で非同期読み取り/ダウンロードについて詳しく説明します。

 public class AlarmEditPresenter implements IModelReciver { @Inject public IModelLoader modelSaver; private int id; private AlarmEdit view; public void onCreate(IAlarmEdit alarmEdit) { //   ,   //   this.view = alarmEdit; // id    Bundle bundle = view.getViewBundle(); id = bundle.getInt(MainScreenPresenter.BUNDLE_ARG_ALARM_ID); //   ,     // ,      //    . alarmListModel.takeAlarmForEdit(id); //     view.setAlarmName(alarmListModel.getEditingAlarm().getName()); //  ,   //     modelSaver.setReciver(this); } public void onClick(AlarmEdit.ClickSourceItem clickItem) { switch(clickItem) { case SAVE: // ,    alarmListModel.getEditingAlarm().setName(view.getAlarmName()); //     alarmListModel.updateAlarm(alarmListModel.getEditingAlarm()); //   . modelSaver.saveModel(); //   . //     . break; case CANCEL: //     . view.setResult(Activity.RESULT_CANCELED); view.finish(); break; } } @Override public void update(String event) { if(event.equals(IModelLoader.EVENT_ALARM_MODEL_SAVE)) { // ,   . // . view.setResult(Activity.RESULT_OK); view.finish(); } } } 

実際、このプレゼンターにはまだ多くのコードがありますが、MVPの観点から新しいものはないため、引用しませんでした。

プレゼンターには、このようなクラスのメンバーもいることに注意してください。

 @Inject private IDateHolder dateHolder; 

テストで必要な時間とロケールをシミュレートするためにIDateHolderが必要です。実際のアプリケーションでは、Roboguiceはシステムの時間とロケールを返すクラスに置き換えます。
特に、メインウィンドウには現在の時刻が表示されます。これは、現在のロケールの時刻を表示する行です。 必要な時間とロケールをシミュレートし、正しいロケールの行がビューに入ったことを確認するテストがあります。 これらのテストのおかげで、私のプログラムは異なるロケールで正しく動作するはずです。

プレゼンターテスト

プレゼンターでは、他のコンポーネントとのすべての通信がインターフェイスを介して行われるため、これらのインターフェイスをテストでシミュレートできます。 私は今何をするつもりです。

このテストには、AlarmEditPresenterをチェックするタスクがあります。 フォームからIDを取得し、モデルから目的のアラームを取得し、その名前を編集コントロールに正しく表示していることを確認する必要があります。

 public class TestAlarmEditPresenter extends RoboUnitTestCase<TestApplication> { public class AlarmEditModule extends AbstractAndroidModule { //       presenter- //   RoboGuice    presenter  //          @Override protected void configure() { bind(AlarmEditPresenter.class); bind(IAlarmListModel.class) .toProvider(AlarmListModelProvider.class); } } private IAlarmListModel model; @Override protected void setUp() throws Exception { TestApplication.alarmTestModule = new AlarmEditModule(); super.setUp(); model = AndroidMock.createNiceMock(IAlarmListModel.class); AlarmListModelProvider.alarmListModel = model; } //    private void initializeTest() { AndroidMock.reset(model); } /** *          View * @throws Exception */ @MediumTest public void testAlarmEditOpen() throws Exception { initializeTest(); AlarmItem alarm = new AlarmItem(); alarm.setName("Test Name"); //,   2     model.takeAlarmForEdit(2); //  ,    presenter AndroidMock.expect(model.getEditingAlarm()).andStubReturn(alarm); AndroidMock.replay(model); //    Intent   //,     2 Bundle bundle = new Bundle(); bundle.putInt(MainScreenPresenter.BUNDLE_ARG_ALARM_ID, 2); AlarmEdit view = AndroidMock.createMock(AlarmEdit.class); AndroidMock.expect(view.getViewBundle()).andStubReturn(bundle); //      View view.setAlarmName("Test Name"); AndroidMock.replay(view); //  presenter AlarmEditPresenter presenter = getInjector().getInstance(AlarmEditPresenter.class); //  presenter.onCreate(view); //,      ,    AndroidMock.verify(view); //,        AndroidMock.verify(model); } } 

ネストされたAlarmEditModuleクラスとそのconfigure（）メソッドについては、次の記事を読んで、RoboGuiceの使用について詳しく見ていきます。

setUp（）メソッドで、シミュレーションを作成してプロバイダーに配置します。 一般に、なぜプロバイダーが必要なのですか。それで、次の問題を解決します。 Inject属性でマークされたフィールドを初期化するとき、必要なシミュレーションを置き換える必要があります。 フィールドタイプ別のRoboGuiceでは、そのようなプロバイダー（configure（）メソッドを参照）を使用する必要があることがわかります。このプロバイダーを介して、必要なシミュレーションを置き換えます。

各テストの前に実行されるinitializeTest（）メソッドでは、他のテストの後にすべてのシミュレーションの状態をクリアして、テストが確実に分離されるようにします。

テスト自体では、最初にシミュレーションを準備します。
アラームを作成し、プレゼンターが編集可能なアラームを要求した場合、この準備されたアラームを彼に返すようにシミュレートされたモデルに伝えます。

 AndroidMock.expect(view.getViewBundle()).andStubReturn(bundle); 

また、特定の呼び出しが期待されることを示します。

 //,   2     model.takeAlarmForEdit(2); ..... //      View view.setAlarmName("Test Name"); 

その後、RoboGuiceを介してAlarmEditPresenterクラスのインスタンスが作成されます。 必ずRoboGuiceを使用して作成し、 Inject属性でマークされたすべてのフィールドに必要な値が入力されるようにしてください。
次に、メソッドpresenter.onCreate（view）を呼び出します。このメソッドでは、アラームがロードされ、その名前がビューに転送されます。

そして最後に、プレゼンターが必要なすべての呼び出しを行ったことを確認します。

 //,      ,    AndroidMock.verify(view); //,        AndroidMock.verify(model); 

残りの詳細を明確にするために、以下についてお話します。

AndroidMock

これは、シミュレーションを作成するためのフレームワークです。 詳細についてはこちらをご覧ください。
code.google.com/p/android-mock

ここでは、AndroidMockの一般的な概要と、プロジェクトで使用したAndroidMockの機能について説明します。

すべてのMock Frameworkおよびすべての言語は、次の目的で設計されています。

まず、特定のインターフェイスまたはクラスを模倣します。 シミュレーションは、インターフェイスまたはクラスのインスタンスであり、元のインターフェイスまたはクラスのインスタンスが必要なすべてのメソッドに渡すことができます。 作成直後の模倣には、タイプに応じて0またはnullの値がありますが、すべてのフィールドがあり、タイプに応じて0またはnullでもあるメソッドを呼び出すことができます。

シミュレーションで何が呼び出されるかが問題でない場合、またはシミュレーションがテストで単に使用されないが、テストクラスがシミュレーションなしで作成されない場合、空のシミュレーションが1行で作成され、作成されたクラスに渡されます。

第二に。 シミュレートするために、そのようなメソッドへの呼び出しが発生した場合にそのような値を返すように1行で指定できます。 上記の例では、これは次の行です。

 AndroidMock.expect(view.getViewBundle()).andStubReturn(bundle); 

通常、この模倣の可能性は、インターフェイスを実装するクラスの準備が整っていない場合、またはメソッドの準備が整っている場合に使用されますが、正しく機能するためには準備に時間がかかります。 また、通常はテストの対象でもないメソッドのデータの準備に煩わされないように、返される結果を単純にシミュレートする方が簡単です。
ちなみに、2つの呼び出しが予想され、それらが異なる結果を返す必要がある場合、次のように記述します。

 AndroidMock.expect(view.getViewBundle()).andReturn(bundle1); AndroidMock.expect(view.getViewBundle()).andReturn(bundle2); 

第三に。 シミュレートするテストを実行した後、必要な呼び出しはすべて完了したが、必要な呼び出しは完了していないことを確認できます。
私の例では、これは次の行です。

 AndroidMock.verify(view); 

彼女はチェックします。 行の前に記述されたすべての期待

 AndroidMock.replay(view); 

実現した。

メソッド呼び出しの事実だけでなく、メソッドが正しい引数で呼び出されていることを確認する必要があります。

 AndroidMock.expect(view.getViewBundle(1)).andReturn(bundle1); AndroidMock.expect(view.getViewBundle(2)).andReturn(bundle2); 

この場合、異なる引数に対して異なる値が返され、検証中に、指定された引数で呼び出しがあったことを検証できます。

シミュレーションを作成する場合、3つの方法があります。
AndroidMock.createNiceMock（） -弱いシミュレーションを作成します。 このチェックでは、追加のメソッドが呼び出されたことは考慮されません。 宣言されたメソッドのみが呼び出されます。 通常は、正しいメソッドが呼び出されたことを追跡する必要がある場合に使用され、余分なメソッドがあれば怖くない。
クラスを作成するためだけにシミュレーションが必要な場合は、弱いシミュレーションを使用し、テスト後にテストを呼び出すことさえしません。

AndroidMock.createMock（） -通常のシミュレーションを作成します。 必要なすべてのメソッドが呼び出され、不要なメソッドが呼び出されなかったことを確認します。 これにより、コール数が確認されます。 通常、期待を記述する1行は1回の呼び出しです。 しかし、andStubReturn（）メソッドを使用する場合、これは多くの呼び出しになります。 また、特定のコール数を表示することもできます：andReturn（）。Times（3）;

AndroidMock.createStrcitMock（） -厳密なシミュレーションを作成します。 この場合、メソッド呼び出しの順序もチェックされます。

詳細なヘルプ情報は、AndroidMockおよびEasyMockプロジェクトページで見つけることができます。

残念ながら、AndroidMockには重大な欠陥があります。
MediaPlayerなどの組み込みクラスを模倣できることが発表されていますが、これはかなり前のことであり、最新バージョンのAndroid SDKでは機能しません。
メインクラスから必要なすべてのメソッドを含む独自のインターフェイスを作成し、実際のMediaPlayerのインスタンスを含み、インターフェイスからのすべての呼び出しを実際のクラスのメソッドにマップするビューを作成する必要があります。
テストでは、作成したインターフェイスをシミュレートします。

そこで、シミュレーションを作成するための別のフレームワークを探します。

他の記事を読む

- はじめに
-MVPおよび単体テスト。 ジェダイ・ウェイ
-ユーザーインターフェイス、テスト、AndroidMock
- データの保存。 ドメインモデル、リポジトリ、シングルトンおよびBDD
-サーバー側の実装、RoboGuice、テスト
-小さなタスク、設定、ロギング、ProGuard