🚄 🎱 🧑🏽‍🤝‍🧑🏼 Androidアプリを段階的に構築する、パート3 💄 📿 👩🏽‍🔧

記事の第1部と第2部では、 Githubと連携するためのアプリケーションを作成し、Dagger 2を実装し、ユニットコードをテストでカバーしました。最後の部分では、統合テストと機能テストを作成し、TDD手法を検討し、その使用に合わせて新しい機能を作成し、次に読むべきことを説明します。

完全なコンテンツ

はじめに

記事の最初の部分では、githubを2段階で操作するための簡単なアプリケーションを作成しました。アプリケーションアーキテクチャは、単純な部分と複雑な部分の2つの部分に分けられました。 2番目の部分では、Dagger 2を実装し、Robolectric、Mockito、MockWebServer、およびJaCoCoを使用したテストでユニットコードをカバーしました。

条件付き適用スキーム

クラス図

テストカバレッジ

コンポーネント相互作用図

すべてのソースコードはGithubにあります。

ステップ5.統合テスト

統合テストは、個々のソフトウェアモジュールをグループで組み合わせてテストするソフトウェアテストのフェーズの1つです。

統合テストには3つのアプローチがあります。

ボトムアップ（ボトムアップ統合）

低レベルのモジュール、プロシージャ、または関数はすべてまとめられ、テストされます。その後、次のレベルのモジュールで統合テストを実施します。このアプローチは、開発レベルのすべてまたはほとんどすべてのモジュールの準備が整っている場合に有用と考えられます。また、このアプローチは、テスト結果からアプリケーションの準備状況のレベルを判断するのに役立ちます。

トップダウン統合

最初に、すべての高レベルモジュールがテストされ、徐々に低レベルモジュールが追加されます。下位レベルのすべてのモジュールは、同様の機能を備えたプラグによってシミュレートされ、準備ができたら、実際のアクティブなコンポーネントに置き換えられます。したがって、上から下へテストを実施します。

ビッグバン（「ビッグバン」統合）

開発されたすべてまたはほとんどすべてのモジュールは、完全なシステムまたはその主要部分として組み立てられ、統合テストが実行されます。このアプローチは、時間を節約するのに非常に適しています。

すべてのモジュールが用意されているので、 ボトムアップアプローチを使用します。

反復アプローチ

反復アプローチを使用します。つまり、モジュールを1つずつ、ボトムアップで接続します。最初に、API +モデルの束、次にAPI +モデル+マッパー+プレゼンター、次に一般的なAPI +モデルマッパー+プレゼンター+ビューを確認します。

否定的および肯定的なシナリオ

統合テストでは、サーバーからの2つの応答シナリオを検討する必要があります。通常の応答とエラーです。これに応じて、コンポーネントの動作が変わります。各テストの前に、サーバー（MockWebServer）からの応答を構成し、結果を確認できます。

統合テストスキーム（API +モデル）：

統合テストの例（API +モデル）、RetrfofitモジュールとModelImplの相互作用を確認します。

統合テストの例

@Test public void testGetRepoList() { TestSubscriber<List<RepositoryDTO>> testSubscriber = new TestSubscriber<>(); model.getRepoList(TestConst.TEST_OWNER).subscribe(testSubscriber); testSubscriber.assertNoErrors(); testSubscriber.assertValueCount(1); List<RepositoryDTO> actual = testSubscriber.getOnNextEvents().get(0); assertEquals(7, actual.size()); assertEquals("Android-Rate", actual.get(0).getName()); assertEquals("andrey7mel/Android-Rate", actual.get(0).getFullName()); assertEquals(26314692, actual.get(0).getId()); }

統合テストスキーム（API +モデル+マッパー+プレゼンター）：

統合テストの例（API +モデル+マッパー+プレゼンター）

 @Test public void testLoadData() { repoInfoPresenter.onCreateView(null); repoInfoPresenter.onStop(); verify(mockView).showBranches(branchList); verify(mockView).showContributors(contributorList); } @Test public void testLoadDataWithError() { setErrorAnswerWebServer(); repoInfoPresenter.onCreateView(null); repoInfoPresenter.onStop(); verify(mockView, times(2)).showError(TestConst.ERROR_RESPONSE_500); }

その結果、すべてのモジュールの相互作用の完全なチェックがボトムアップで取得されます。モジュールがどこかで正しく相互作用しない場合、テストを通じてこれをすぐに確認できます。

ステップ6.機能テスト

機能テストは、機能要件の実現可能性、つまり特定の条件下でユーザーが必要とするタスクを解決するソフトウェアの能力を検証するためのソフトウェアテストです。機能要件により、ソフトウェアの機能、解決するタスクが決まります。

Androidアプリケーションの一部として、ユーザーの視点からアプリケーションをテストします。まず、カスタムアプリケーションマップを作成します。

アプリケーションマップ

必要なテストケースを作成します。

アプリケーションを開き、すべての要素の可視性を確認します
テストユーザーを入力し、[検索]をクリックします
- 受信したデータ-リポジトリのリストを取得し、データ表示を確認します。
- データを受信していません-エラー表示を確認してください。
2番目の画面に移動し、ユーザー名とリポジトリ名が正しく表示されているかどうかを確認します。
- ブランチと貢献者のリストを取得し、データ表示を確認
- 受信されなかったリスト（2つのテスト）、受信されたリストの表示、エラー表示を確認します
- 両方のリストが受信されない、エラー表示を確認する

テストには、エスプレッソを使用します。他のテストと同様に、モックと事前に準備されたjsonファイルを使用して、インターネットからアプリケーションを分離します。 Dagger 2は、これとコンポーネントの置換に役立ちます。

MockTestRunnerとTestAppコード

 public class MockTestRunner extends AndroidJUnitRunner { @Override public Application newApplication( ClassLoader cl, String className, Context context) throws InstantiationException, IllegalAccessException, ClassNotFoundException { return super.newApplication( cl, TestApp.class.getName(), context); } } public class TestApp extends App { @Override protected TestComponent buildComponent() { return DaggerTestComponent.builder().build(); } }

エスプレッソテストの例

 @Test public void testGetUserRepo() { apiConfig.setCorrectAnswer(); onView(withId(R.id.edit_text)).perform(clearText()); onView(withId(R.id.edit_text)).perform(typeText(TestConst.TEST_OWNER)); onView(withId(R.id.button_search)).perform(click()); onView(withId(R.id.recycler_view)).check(EspressoTools.hasItemsCount(7)); onView(withId(R.id.recycler_view)).check(EspressoTools.hasViewWithTextAtPosition(0, "Android-Rate")); onView(withId(R.id.recycler_view)).check(EspressoTools.hasViewWithTextAtPosition(1, "android-simple-architecture")); onView(withId(R.id.recycler_view)).check(EspressoTools.hasViewWithTextAtPosition(2, TestConst.TEST_REPO)); } @Test public void testGetUserRepoError() { apiConfig.setErrorAnswer(); onView(withId(R.id.edit_text)).perform(clearText()); onView(withId(R.id.edit_text)).perform(typeText(TestConst.TEST_OWNER)); onView(withId(R.id.button_search)).perform(click()); onView(allOf(withId(android.support.design.R.id.snackbar_text), withText(TestConst.TEST_ERROR))) .check(matches(isDisplayed())); onView(withId(R.id.recycler_view)).check(EspressoTools.hasItemsCount(0)); }

同様に、テストケースの残りのテストを記述します。

Espressoでの作業が終了したら、モジュール式の統合テストと機能テストでアプリケーションを完全にカバーします。

ステップ7. TDD

テスト駆動開発とは、テストの作成を通じて開発を定義するソフトウェア開発手法です。

基本的に、次の3つの簡単な繰り返し手順を実行する必要があります。

-追加する必要がある新しい機能のテストを作成します。

-テストに合格するコードを記述します。

-新しいコードと古いコードをリファクタリングします。

略語TDDになじみがない場合は、iOS部門の同僚からの記事またはTDDハブからの記事を読むことをお勧めします。

TDDには3つの法則があります。

本番コードは、アイドルテストが行われる前に作成されません。
エラーに十分な数の単体テストコードは書き込まれません。
現在のアイドルテストに合格するのに十分な量のプロダクションコードは書き込まれません。

たとえば、インターネットからのダウンロードを表示するプログレスバーを作成します。データがダウンロードされると表示され、データがロードされるかエラーが発生すると表示されなくなります。すべての開発はTDDで行われます。

この機能の開発は、プレゼンターとフラグメントに影響し、マッパーと日付レイヤーは変更されません。

発表者

リポジトリのリストから始めましょう。まず、インターフェースを追加しましょう。

 public interface RepoListView extends View { void showRepoList(List<Repository> list); void showEmptyList(); String getUserName(); void startRepoInfoFragment(Repository repository); //New void showLoading(); void hideLoading(); }

最初の段階。

最初に、通常のロードの場合、フラグメントでshowLoadingメソッドが呼び出されたことを確認するテストを作成します。

 @Test public void testShowLoading() { repoListPresenter.onSearchButtonClick(); verify(mockView).showLoading(); }

壊れたテストを取得したらすぐに、合格するコードを記述します。

 public void onSearchButtonClick() { String name = view.getUserName(); if (TextUtils.isEmpty(name)) return; view.showLoading(); // --- some code --- }

リファクタリングするものはまだありません。

これが最初のTDD開発の反復が終了した場所です。新しい機能とそのテストを取得しました。

第二段階。

通常のロード後に、フラグメントに対してhideLoadingメソッドが呼び出されたことを確認するテストを作成します。

 @Test public void testHideLoading() { repoListPresenter.onSearchButtonClick(); verify(mockView).hideLoading(); }

テストに合格するコードを記述します。

 //-- view.showLoading(); Subscription subscription = model.getRepoList(name) .map(repoListMapper) .subscribe(new Observer<List<Repository>>() { @Override public void onCompleted() { view.hideLoading(); } @Override public void onError(Throwable e) { view.showError(e.getMessage()); } @Override public void onNext(List<Repository> list) { if (list != null && !list.isEmpty()) { repoList = list; view.showRepoList(list); } else { view.showEmptyList(); } } });

リファクタリングは必要ありません。

3番目と4番目のステージ。

次に、エラーが発生したときに必要なメソッドが正しく呼び出されたことを確認するテストを作成します。

エラー処理テスト

 @Test public void testShowLoadingOnError() { doAnswer(invocation -> Observable.error(new Throwable(TestConst.TEST_ERROR))) .when(model) .getRepoList(TestConst.TEST_OWNER); repoListPresenter.onSearchButtonClick(); verify(mockView).showLoading(); } @Test public void testHideLoadingOnError() { doAnswer(invocation -> Observable.error(new Throwable(TestConst.TEST_ERROR))) .when(model) .getRepoList(TestConst.TEST_OWNER); repoListPresenter.onSearchButtonClick(); verify(mockView).hideLoading(); }

エラー処理コード

 //-- @Override public void onError(Throwable e) { view.showError(e.getMessage()); view.hideLoading(); } //--

リファクタリングは必要ありません。レポリストプレゼンターとの作業は完了しました。レポ情報プレゼンターに移りましょう。

リポジトリ情報プレゼンター

前のステップと同様に、正しいデータをロードするためのテストとコードを作成します。

正しいデータ読み込みのテスト

 @Test public void testShowLoading() { repoInfoPresenter.onCreateView(null); verify(mockView).showLoading(); } @Test public void testHideLoading() { repoInfoPresenter.onCreateView(null); verify(mockView).hideLoading(); }

データを正しくロードするためのコード

 public void loadData() { String owner = repository.getOwnerName(); String name = repository.getRepoName(); view.showLoading(); Subscription subscriptionBranches = model.getRepoBranches(owner, name) .map(branchesMapper) .subscribe(new Observer<List<Branch>>() { @Override public void onCompleted() { hideInfoLoadingState(); } @Override public void onError(Throwable e) { view.showError(e.getMessage()); } @Override public void onNext(List<Branch> list) { branchList = list; view.showBranches(list); } }); addSubscription(subscriptionBranches); Subscription subscriptionContributors = model.getRepoContributors(owner, name) .map(contributorsMapper) .subscribe(new Observer<List<Contributor>>() { @Override public void onCompleted() { hideInfoLoadingState(); } @Override public void onError(Throwable e) { view.showError(e.getMessage()); } @Override public void onNext(List<Contributor> list) { contributorList = list; view.showContributors(list); } }); addSubscription(subscriptionContributors); } protected void hideInfoLoadingState() { countCompletedSubscription++; if (countCompletedSubscription == COUNT_SUBSCRIPTION) { view.hideLoading(); countCompletedSubscription = 0; } }

リファクタリング

ご覧のとおり、2人のプレゼンターに同じコードが使用されています（ダウンロードインジケーターの表示と非表示、エラーの表示）。共通の基本クラスBasePresenterに配置する必要があります。 BasePresenterでshowLoadingState（）hideLoadingState（）およびshowError（Throwable e）メソッドを引き出します

BasePresenterコード

 protected abstract View getView(); protected void showLoadingState() { getView().showLoadingState(); } protected void hideLoadingState() { getView().hideLoadingState(); } protected void showError(Throwable e) { getView().showError(e.getMessage()); }

RepoInfoPresenterをリファクタリングし、すべてのテストに合格することを確認します。 RepoListPresenterをリファクタリングして基本クラスを操作することを忘れないでください。

次に、最初にテストを記述し、次に（RepoInfoPresenterの）ロード中にエラーを処理するためのコードを記述します。

起動中のエラー処理のテスト

 @Test public void testShowLoadingOnError() { doAnswer(invocation -> Observable.error(new Throwable(TestConst.TEST_ERROR))) .when(model) .getRepoContributors(TestConst.TEST_OWNER, TestConst.TEST_REPO); doAnswer(invocation -> Observable.error(new Throwable(TestConst.TEST_ERROR))) .when(model) .getRepoBranches(TestConst.TEST_OWNER, TestConst.TEST_REPO); repoInfoPresenter.onCreateView(null); verify(mockView).showLoading(); } @Test public void testHideLoadingOnError() { doAnswer(invocation -> Observable.error(new Throwable(TestConst.TEST_ERROR))) .when(model) .getRepoContributors(TestConst.TEST_OWNER, TestConst.TEST_REPO); doAnswer(invocation -> Observable.error(new Throwable(TestConst.TEST_ERROR))) .when(model) .getRepoBranches(TestConst.TEST_OWNER, TestConst.TEST_REPO); repoInfoPresenter.onCreateView(null); verify(mockView).hideLoading(); } @Test public void testShowLoadingOnErrorBranches() { doAnswer(invocation -> Observable.error(new Throwable(TestConst.TEST_ERROR))) .when(model) .getRepoBranches(TestConst.TEST_OWNER, TestConst.TEST_REPO); repoInfoPresenter.onCreateView(null); verify(mockView).showLoading(); } @Test public void testHideLoadingOnErrorBranches() { doAnswer(invocation -> Observable.error(new Throwable(TestConst.TEST_ERROR))) .when(model) .getRepoBranches(TestConst.TEST_OWNER, TestConst.TEST_REPO); repoInfoPresenter.onCreateView(null); verify(mockView).hideLoading(); }

起動時にエラーを処理するためのコード

 showLoadingState(); Subscription subscriptionBranches = model.getRepoBranches(owner, name) .map(branchesMapper) .subscribe(new Observer<List<Branch>>() { @Override public void onCompleted() { hideInfoLoadingState(); } @Override public void onError(Throwable e) { hideInfoLoadingState(); showError(e); } @Override public void onNext(List<Branch> list) { branchList = list; view.showBranches(list); } }); addSubscription(subscriptionBranches); Subscription subscriptionContributors = model.getRepoContributors(owner, name) .map(contributorsMapper) .subscribe(new Observer<List<Contributor>>() { @Override public void onCompleted() { hideInfoLoadingState(); } @Override public void onError(Throwable e) { hideInfoLoadingState(); showError(e); } @Override public void onNext(List<Contributor> list) { contributorList = list; view.showContributors(list); } });

プレゼンターの開発は終了しました。フラグメントに渡します。

フラグメント

共通の要素としてのプログレスバーはアクティビティ内にあり、フラグメントはアクティビティのshowProgressBar（）およびhideProgressBar（）メソッドを呼び出し、プログレスバーを表示または非表示にします。アクティビティを操作するには、ActivityCallbackインターフェイスを使用します。プレゼンターの経験から、共通の基本クラスであるBaseFragmentが必要であるとすぐに推測できます。アクティビティとの相互作用のロジックが含まれます。

最初に、基本フラグメントとアクティビティの相互作用に関するテストを作成し、次にコードを作成します。

基本フラグメントテスト

 @Test public void testAttachActivityCallback() throws Exception { assertNotNull(baseFragment.activityCallback); } @Test public void testShowLoadingState() throws Exception { baseFragment.showLoading(); verify(activity).showProgressBar(); } @Test public void testHideLoadingState() throws Exception { baseFragment.hideLoading(); verify(activity).hideProgressBar(); }

基本フラグメントコード

 @Override public void onAttach(Activity activity) { super.onAttach(activity); try { activityCallback = (ActivityCallback) activity; } catch (ClassCastException e) { throw new ClassCastException(activity.toString() + " must implement activityCallback"); } } @Override public void showLoading() { activityCallback.showProgressBar(); } @Override public void hideLoading() { activityCallback.hideProgressBar(); }

リファクタリングは不要です。アクティビティに進んでください。

活動性

最後のステップは、アクティビティインターフェイスを実装することです。コマンドに応じて、progressBarのsetVisibilityを変更します。テストでは、progressBarが検出され、showProgressBarメソッドとhideProgressBarメソッドが機能することを確認する必要があります。

最初にテストを作成します。

アクティビティテスト

 @Test public void testHaveProgressBar() throws Exception { assertNotNull(progressBar); } @Test public void testShowProgressBar() throws Exception { mainActivity.showProgressBar(); verify(progressBar).setVisibility(View.VISIBLE); } @Test public void testHideProgressBar() throws Exception { mainActivity.hideProgressBar(); verify(progressBar).setVisibility(View.INVISIBLE); }

次に、コードを記述します。

アクティビティコード

 @Bind(R.id.toolbar_progress_bar) protected ProgressBar progressBar; //---- some code ---- @Override public void showProgressBar() { progressBar.setVisibility(View.VISIBLE); } @Override public void hideProgressBar() { progressBar.setVisibility(View.INVISIBLE); }

すべてが非常に簡単で、リファクタリングは必要ありません。

これで、TDD手法を使用したプログレスバーの開発を終了します。

ステップ8.次は何ですか？

TDDを研究し、ロードマッピングを開発したら、アプリケーションの開発を終了します。さらなる開発のために、次の記事を読むことをお勧めします。

Android Clean Architecture

Android Clean ArchitectureはFernando Cejasの有名な記事で、Uncle BobのClean Architectureに基づいています。プレゼンテーション層、ドメイン層、データ層の3つの層の間の相互作用が考慮されます。 habrahabrへの翻訳があります。

VIPER

VIPER（View、Interactor、Presenter、Entity、Routing）の人気が高まっています。VikkoSの記事VIPER Jet-powered VIPERで詳しく知ることができます。 VIPERの主要な原則は、iOSの同僚からの記事とレポートで取り上げられています。

モスビー

Mosbyは、MVPアプリケーションを作成するための一般的なライブラリです。すべてのメインインターフェイスと基本クラスが含まれています。ウェブサイト： http : //hannesdorfmann.com/mosby/ Github： https : //github.com/sockeqwe/mosby

Androidアプリケーションアーキテクチャ

Ribotチームのアーキテクチャに関する良い記事-Androidアプリケーションアーキテクチャ。 AsyncTaskからRxJavaへの移行が考慮されます。最近、 habrahabrへの翻訳がリリースされました。

Android開発文化文書

Android開発カルチャードキュメントArtem_zinによる #qualitymatters Artem Zinnatullinによる素晴らしい記事とデモプロジェクト。この記事では、Androidアプリケーションを開発するための8つの原則について説明しています。Githubの例でサポートされています。

おわりに

この一連の記事では、アプリケーション開発のすべての段階について説明しました。シンプルなMVPベースのアーキテクチャから始めたため、新しい機能を追加するのが難しくなりました。リアクティブプログラミングとコールバックを取り除くためのRxJavaとRxAndroid、ネットワークとの便利な作業のためのRetrofit、迅速で簡単なビュー検索のためのButterknifeなどの最新のライブラリを使用しました。 Dagger 2はすべての依存関係を管理し、テストの作成時に非常に貴重なサポートを提供しました。 jUnit、Robolectric、Mockito、MockWebServerを使用して、テスト自体を作成しました。そして、エスプレッソは、テスターを回帰テストの苦労から救いました。

プロジェクトをテストで完全にカバーしました。単体テストでは各コンポーネントを個別にテストし、統合テストでは全体的な相互作用をテストし、機能テストではすべてをユーザー側から調べます。プログラムをさらに変更しても、一部のコンポーネントが破損することを恐れることはできません（まあ、またはほとんど恐れません）。何かが落ちて、リリースにバグが入り込みます。 TDDのおかげで、ほとんどのコードはテストでカバーされます（テストなし、コードなし）。部分的なカバレッジや「コードは作成されましたが、テストの時間はありませんでした」という問題はありません。

すべてのプロジェクトコードはGithub（https://github.com/andrey7mel/android-step-by-step）で入手できます

このシリーズの記事をお楽しみいただき、お役に立てば幸いです。ご清聴ありがとうございました。

Androidアプリを段階的に構築する、パート3