Android開発のデザインパターン。 パート2-MVPおよび単体テスト。 ジェダイ・ウェイ

最初は、MVPとは何かを簡単に説明したかったのですが、うまくいきませんでした。 したがって、この記事を別の記事で強調しました。この記事はAndroidとはほとんど関係ありませんが、MVPと単体テストを理解するために非常に重要です。 約束された記事はどこにも行きません。



すべての開発者はユニットテストが何であるかを知っていますが、それらを使用してプログラムの開発時間を短縮するためにそれらを使用できる人はほとんどいません。 彼らの目では、テストの助けを借りてより速く、より良い仕事をすることができる人は、目を閉じて手にキャベツを持つマシンガンナーの会社を粉砕できるジェダイのように見えます。



ジェダイの道にあなたを置き、目を閉じて単体テストやその他の技術の助けを借りてバグの山を粉砕するように教えます。

モデルビュープレゼンター（MVP）とは

遠くから、MVPとは何か、なぜMVPが必要なのか、MVPの用途は何かを説明します。

どのプロジェクトでも、開発者がユニットテストを追加して、中間バージョンがリリースされる前に行われたすべてのことを最新の変更が壊さないことを確認したい場合があります。



テストの実行内容は明らかなようです。ユーザーがフォームを確認し、フィールドに正しいデータを入力し、このボタンのハンドラーで[保存]をクリックした後、フォームのデータがチェックされてデータベースに入れられたか、ユーザーがエラーメッセージを受け取ることを確認する必要があります。

さまざまな言語のドキュメントにあるすべての例は、この単純な原則に基づいています。 したがって、これは非常に一般的な設計上の決定です。



しかし、フィールドの正確性をチェックしてデータベースに保存するロジックは「保存」ボタンのハンドラーにあるため、最初の問題が発生します。 テストでフォームの「保存」ボタンのクリックをテストするにはどうすればよいですか？ 実際、テストでは、クラス「フォーム」のインスタンスを作成することはできません。ほとんどの場合、このクラスにはパブリックコンストラクターがないためです。言い換えると、フォームはテストにない特別なクラスによって作成されます。



MVPを使用すると、前述の問題を美しく解決できます。 一番下の行は、ボタンハンドラーからすべてのコードを転送して、簡単に作成できる別のクラスに保存する必要があるということです。 このクラスはプレゼンターと呼ばれます。 そして、現在ビューまたはビューと呼ばれているフォームでは、保存ボタンのハンドラーに1行だけが残り、プレゼンターで同じ名前のメソッドが呼び出されます。

通常、プレゼンターはビューコンストラクターで作成され、ビューへの参照がプレゼンターに渡されます。



さらにテストでは、プレゼンターのインスタンスを作成し、プレゼンターの「保存」メソッドの呼び出しをシミュレートします。 さらに、プレゼンターはビューからフォームフィールドの値を取得し、それらをチェックしてデータベースに渡すことを期待しています。 テストのプレゼンターにはまだフォームが必要であり、データベースを操作するために何らかのクラスのフォームのデータベースさえ必要であることがわかりました。



テストでデータベースを操作するためのフォームとクラスを作成することはできませんが、耳で次のフェイントを実行できます：作成されたプレゼンターに、ビューとデータベースを操作するためのクラスではなく、それらのインターフェイスへの参照を受信させます つまり、プレゼンテーション用とデータベース用のインターフェイスを作成する必要があります。 これらのインターフェイスでの通常の作業中、実際のプレゼンテーションとデータベースは非表示になり、テストではこれらのインターフェイスもサポートするスタブクラスを作成します。 テストでは、フォームフィールドの固定値を返すビューのスタブを作成します。 データベースのスタブは、そこに来た値を保存するだけなので、後でこれらの値を確認できます。



そして今、テスト中：

1.クラスを表現用のスタブに作成し、それが返すフィールド値を規定します。

2. SaveToDBメソッドを呼び出すときに、渡された値を単に保存するデータベースのスタブクラスを作成します。

3.プレゼンターを作成し、作成したスタブをプレゼンターに渡します。

4.プレゼンターメソッドを「保存」します

5.必要な値がDBスタブに表示されていることを確認します。そうでない場合、プレゼンターにエラーがあります。



それでは、なぜMVPが必要なのか、そしてそれは何に使用されるのでしょうか。

MVPは、フォームにデータを表示するコードからデータを処理するためのビジネスロジックでコードを分離できる設計パターンです。

プレゼンターのビジネスロジックは、新しいバージョンがリリースされるたびにテストされます。 これにより、プログラムに複雑なエラーはないと言うことができます。

ビュー内のコードはテストされていませんが、これらのエラーは「保存」ボタンが何もしないことを開発者が簡単に発見し、ボタンハンドラーでプレゼンターメソッドを呼び出すのを忘れたことがすぐにわかるため、簡単に修正できます。



この場所の熱心な読者は、「はい、あなたはめちゃくちゃです！」と叫ぶでしょう。 以前は、1つのファイルに収まるクラスが1つあり、その中のすべてをデバッグするのが便利でしたが、今はプレゼンタークラス、インターフェイス、2つのスタブ、およびテスト自体を追加する必要があります！ それには2倍の時間がかかります。 ボスが注文した場合、コードを書いた後、いくつかのテストを行いますが、締め切りについては責任を負いません”

「落ち着いて、若いパダワン」

はい、どのパターンでも追加のコード行を書く必要がありますが、それを利用する方法を理解するだけです。



ほとんどの場合、開発者は単体テストを使用しません。これは、これはテストを記述するための追加時間の無駄であり、テストの恩恵を受けないテスターはこの恩恵を受けるためです。 そのため、プロジェクトでの時間の節約は、テスターの作業が少なく、テストの作成に費やした時間を超えることはできないという事実によってのみ達成できます。



そのため、この方法では単体テストを使用できません。 開発者の時間を節約するために使用する必要があります。



次に、テストを使用して開発プロセスを整理する方法を説明します。これにより、開発者にとってメリットがあります。



例として、データを入力し、「保存」ボタンをクリックし、エラーがある場合はデータを確認し、そうでない場合はユーザーに表示し、そうでない場合はデータベースに送信する必要がある同じフォームを使用します。

プレゼンター用のビューとプリセットの作成

まず、フォーム（ビュー）を作成する必要があります。Androidの場合、これはActivityクラスの相続人です。 値を入力し、エラーメッセージを表示し、ハンドラーで[保存]ボタンを表示するには、コントロールを配置する必要があります。



次に、プレゼンテーションのインターフェイスを作成する必要があります。 プレゼンターがフォームにデータを出力し、フォームからデータを取得できるようにするには、インターフェイスが必要です。そのため、インターフェイスにはsetName（文字列名）や文字列getName（）などのメソッドが必要です。 当然、ビューはこのインターフェイスを実装する必要があり、メソッドでは、値を引数から使用済みコントロールのTextプロパティに、またはgetNameメソッドの場合はその逆に単純にシフトする必要があります。



次に、インターフェイスインスタンスへのリンクを入力として受け取るプレゼンターを作成する必要があります。 今のところ、プレゼンターコンストラクターでは、フォームに任意の値を入力するだけで、プレゼンターがフォームにフルアクセスできることを確認します。

また、「保存」メソッドを作成します。このメソッドでは、ローカル変数のビューフィールドから現在の値を取得し、ブレークポイントを設定して、このメソッドがビューから呼び出されるようにします。



ビューコンストラクターで、プレゼンターのインスタンスを作成し、このビューへのリンクを与えます。 メソッドのビューで、「保存」ボタンのハンドラーは、プレゼンター内の対応するメソッドを呼び出すだけです。



これがビューの例です

public class View extends Activity implements IView { Presenter presenter; public View(Bundle savedInstanceState) { presenter = new Presenter(this); } public void setName(String name) { tvName.setText(name); } public void getName() { return tvName.getText(); } public void onSave(View v) { presenter.onSave(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

発表者の一例です

 public class presenter { IView view; public presenter(IView view) { this.view = view; view.setName("example name"); } public onSave() { string name = view.getName(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の段階のコードの準備ができました。

デバッガでプログラムを実行し、フォームを開いたときに正しい名前が表示されていることを確認する必要があります。新しい名前を入力して[保存]をクリックすると、プレゼンターは正しい値を取得します。



最初の段階では、単体テストはなく、特に時間の節約はありませんが、コストは大きくありません。

「目を閉じて、若いパダワンよ。」

今から楽しみが始まります。 実際、コードをさらに記述することで、フォームがどのように機能するかを見るためにアプリケーションを実行する必要はありません。 テストですべてのコードを開発およびデバッグします。 実際のジェダイのように、「目を閉じて」いるかのようにコードを記述します。



秘密は、プレゼンターを小さなピースに追加し、このピースをテストして、生地を追加することです。



プレゼンター機能を埋めます。 作成時に、データベースから名前を読み取り、ビューに渡す必要があります。 保存するときは、プレゼンテーションから名前を取得し、データベースに保存します。

 public class presenter { IView view; IDataBase dataBase; int Id; public presenter(IView view, IDataBase dataBase) { this.view = view; this.dataBase = dataDase; id = view.getId(); string name = dataBase.loadFromDB(id); view.setName(name); } public onSave() { string name = view.getName(); dataBase.saveToDB(id, name); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

IDを取得するためにインターフェースとビューに新しいメソッドを追加する必要があることは明らかですが、今のところは「目を開ける」、つまりプレゼンテーションを確認するためにアプリケーションを起動することさえしません。 これは後で行いますが、エラーが発生した場合は、すぐに修正します。



そこで、プレゼンテーションの一部を作成し、テストの一部を作成しました。



最初の部分で書いたスタブは、インターフェースをサポートするクラスの形式で作成する必要はありません。 さまざまなMockフレームワークの場合、指定したインターフェイスをサポートし、メソッドを呼び出すときに必要な値を返すクラスのインスタンスを3行で作成できます。 これらのスタブは、単なるスタブよりもはるかに洗練されているため、模倣（モックという言葉の翻訳）と呼ばれます。



試験方法の例

 public void testOpenAndSave() { IView view = createMock(IView.class); //    IDataBase dataBase = CreateMock(IDataBase.class);//    expect(view.getId()).andReturn(1); // presenter       id 1 expect(dataBase.LoadFromDB(1)).andReturn("source name"); // presenter   ,  "source name" expect(view.setName("source name")); //       expect(view.getName()).andReturn("destination name"); // presenter   ,   ,  "destination name". expect(dataBase.SaveToDB(1, "destination name")); //,       . Presenter presenter = new Presenter(view, dataBase); //  presenter       presenter.Save();//   ""; //,          verify(view); verify(dataBase); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストのコードがプレゼンターのコードと同じであるとうめいたりしないでください。 それは価値があります。



テストを実行して、すべてが正常であることを確認するか、すべてが正常になるようにします。



この開発プロセスでは、テストはコードにとって異質なものではありません。 テストは、開発者がタスクを実装するときに発行する必要があるコードです。 記述されたコードが正しく機能することを確認するためのテストが必要です。



プレゼンターのコードを熟考し、テストのコードをすぐに考えてください;これらは完成したタスクの陰と陽であり、各部分は互いに分離不可能です。

そしてここに利益がある

そして今、私は利益が開発時間を短縮し、品質を改善するという形でどこにあるかを示します。



利益は発表者のさらなる発展に現れます。



次に、フォームからsaveメソッドにデータ検証を追加します。 また、テストでは、正しい値がデータベースに保存されていることを確認する必要があり、誤った値についてはエラーメッセージが表示されます。



これを行うには、名前が正しいことを確認するために必要なコードをプレゼンターに追加し、名前が間違っている場合は、setErrorText（）メソッドを呼び出します。データベースへの保存は呼び出さないでください。



次に、テストをコピーして、プレゼンテーション用にシミュレーションを編集します。 getName（）を呼び出すときに間違った名前を返し、正しい引数でsetErrorText（）メソッドが呼び出されるのを待って、エラーメッセージが正しいことを確認する必要があります。 また、データベースのシミュレーションでは、SaveToDBメソッドが呼び出されたことがない、つまり0回呼び出されたことを確認する必要があります。



確認したすべてのテストを実行しますが、新しいテストは正常に機能しています。 しかし、過去は過ぎ去りません。 私たちは愚かな間違いのために額を叩き、すぐに修正しました。

そして今、両方のテストが機能します。



最初のテストではなかった場合、テスターは正しい行でエラーを見つけていたため、ユニットテストを使用するよりも修正に時間がかかります。 コード内の適切な場所を再度開き、アルゴリズムがどのように機能するかを覚えて修正する必要があります。 そして、テストがないので、他のすべてのテストケースを自分でチェックして、このエラーを修正しても別のテストケースにつながらないことを確認してください。



アルゴリズムが複雑で、多数のテストケースをチェックする必要がある場合、時間の節約がより顕著になります。 テストがなければ、アプリケーション全体の起動に時間を費やしてから、いくつかのウィンドウを開いて独自のウィンドウに移動し、テストケースを再生する必要があります。これには多くの労力がかかります。



しかし、テストがあります。 したがって、過去のすべてのテストケースもチェックされるため、さまざまなテストケースを簡単にシミュレートし、バッチでバグを修正できます。



その結果、高品質のコードが得られ、テスターが見つけたエラーから注意をそらす必要がないため時間を節約できました。また、エラーを修正した後、他のすべてのテストケースが壊れなかった最長時間をチェックしました。



そして、数日後、プレゼンター全体がすべてのケースに対して準備が完了し、テストされると、アプリケーションを起動し、すべてのテストケースに適切に機能することがわかります。 そして、私たちは本物のジェダイのように感じます。

ジェダイは簡単になりません。

はい 真のジェダイは、テストサポートが、要件を変更するときに、最初の開発からもたらされるすべての利点を損なうことがないように、テストを記述するための多くのトリックを知っている必要があります。



実際、テストのコピーは、アプリケーションのコードのコピーと同じくらい悪いです。 テストケースを記述するデータ構造で動作するテストを行う必要があります。 このデータ構造には、入力および予想される出力または予想されるエラーが含まれます。

この場合、新しいテストは、異なるデータ構造を使用した同じメソッドの呼び出しです。 そして、すべての構造を処理できるようにテストを開発する必要があります。



インターネット上で、あなたが本当のジェダイマスターになるための多くのトリックを見つけることができると信じています。



主なことは、あなたがすでにジェダイの道に乗り出し、それに従う方法を知っていることです:)

他の記事を読む

- はじめに

-MVPおよび単体テスト。 ジェダイ・ウェイ

- ユーザーインターフェイス、テスト、AndroidMock

- データの保存。 ドメインモデル、リポジトリ、シングルトンおよびBDD

-サーバー側の実装、RoboGuice、テスト

-小さなタスク、設定、ロギング、ProGuard