モバイルアプリケーションのリリースバージョンをビルドするとき、debug = falseを設定してapkファイルをエクスポートすることになったのを思い出します。 IDEがパフするのに2分かかり、完了です。 すべての努力は、署名証明書のデータを指定する必要性に焦点を合わせました。 つい最近でした。 今では、そのアプリケーションのアセンブリプロセスが非常に大きくなったため、すべての操作を自分で突然実行する必要があり、すべてを覚えて正しく実行しても（信じられない）、1時間はかかりません。そして、おそらく1日後、セラピストは疲労のために2週間の病気休暇を処方する必要があります。



だから、モバイルアプリケーションを構築するプロセス。 特定のモバイルチームのCI（ポーカー、人魚、その他の必須属性を含む）に関する投稿を最近流行しているからではなく、これが私が得た素晴らしい経験だからです。 Android用のMail.Ru Mailで作業している間、そしてこの可能性はほとんど存在しないため、私は別のチーム、別のプロジェクト、または別の会社で働きます。



どのプロセスでも、重要な決定は、アセンブリ全体の構築に基づいてシステムを選択することです。 ビルドはビルドサーバーで処理する必要があります。 これは論理的です。 しかし、どちらを選択するのですか？



質問は曖昧です。誰もが自分の経験、システムが直面しているタスク、および所有しているリソースに基づいて1つまたは別のソリューションを選択します。 無料のソリューションが好きな人は、マネージャーに年間N000ドルが必要だったことと、それなしではできない理由をマネージャーに説明する必要がないためです。 コミュニティの存在や、これらの決定をすでに活用し、結果に満足している膨大な数のチームの経験に刺激されています。 視点の数は、この質問をした人の数と同じ傾向があります。 誰かの議論が真実である、または誰かの反対が無関係であると言うことはできません。 しかし、そのような問題に直面した開発者の意見がどうであれ、市場で人気のあるすべてのソリューションは概して、セットアップの容易さ、関連システムとの統合、拡張オプション、およびコミュニティまたはシステム開発者からのサポートのみが異なることに同意します。



一般に、ビルドサーバーの選択は、個別のholivarのトピックです。 AtlassianのBamboo Build Serverソリューションを選択したとしか言えません。 主な理由はいくつかありますが、そのうちの1つは、プロジェクトで使用する課題追跡システムとの統合の容易さ、およびコードレビューシステムとリポジトリホスティングです。 みんな素晴らしいです。すべてが便利で、すべて手元にあり、最も重要なのは、提供されるほとんどすべてのソリューションとオプションが、チームの開発プロセスに完全に適合することです。

竹

Bambooは非常に一般的なソリューションであり、世界中の膨大な数のチームで使用されています。 このCI / CDツールの作業スキームの詳細は公式ドキュメントWebサイトで見つけることができますが、用語の違いを避けるために、このドキュメントの一部を無料で翻訳できるようにします。



Continuous Integrationサーバーのタスクは、プロジェクトのテスト環境へのアセンブル、テスト、デプロイのすべての作業を行うことです。 CIサーバーはリポジトリと通信し、プロジェクトの特定のリビジョンを受け取り、必要なすべてのアクションを実行し、完成したアセンブリ結果をプロジェクトチームに提供します。

プロジェクト	1つ以上のビルドプランで構成されます プロジェクトのすべてのビルド計画に関するレポートを提供します 他のアプリケーション（Jira、Fisheye、Crucible、Stash）にリンク
ビルドプラン （計画）	1つ以上のステージで構成されます すべてのステージが順番に実行され、同じリポジトリを使用します プロジェクトの他のビルドプランに応じて、ビルドを起動するためのルールが含まれています
ステージ （ステージ）	1つ以上の作品で構成されています 並行して作業を実行します。フリービルドエージェントでは、すべての作業が正常に完了すると完了したと見なされます 後続のアセンブリステージのアーティファクトを転送します。
仕事 （仕事）	1つ以上のタスクで構成されます 内部のすべてのタスクは同じエージェントで順番に実行されます
挑戦する （タスク）	プロジェクトのリビジョンのチェックアウト、スクリプトの実行などの個別の操作。

多かれ少なかれ同様の分離は、あらゆるアセンブリシステムで利用でき、プロセス全体の構築に必要な柔軟性を提供します。 一見、これは過度の複雑さのようです。 Bambooを使い始めたばかりのプロジェクトでしたが、徐々にすべてが落ち着き、アセンブリプロセス全体のどの部分をスケーリングする必要があるのか​​、孤立したままにする必要があるか、そして提案されたコンセプトの枠組み内でかなり調和のとれた構造が明らかになりました。



一般に、ビルドサーバーまたはCIサーバーはソフトウェア開発プロセスの自動化の重要な部分であることをよく理解する必要があります。 このモジュールに、市場にリリースするためのアプリケーションを準備するさまざまな段階とレベルで実行する必要があるすべてのタスクと作業を割り当てると、一種のアプリケーションリリースパイプラインが得られます。 また、特定のビルドに含まれるタスク、現在のリリースの段階、新しい機能を統合する際に発生する問題、修正プログラムの準備の段階などを簡単に判断できます。



そのため、チームでこれがどのように行われたかの説明にスムーズにアプローチしました。

タスク

アセンブリプロジェクトはいくつかの段階に分かれており、現在の主なタスクを反映しています。

• ビルド-リリースパイプラインで必要になる可能性のあるすべてのビルドオプション（アルファ、ベータ、リリース）が含まれます。 はい、はい、プロジェクトアセンブリは私たちの間で異なり、そのステータスだけではありません。 製品の違い：さまざまなリソース、設定の有無など。
• 検証は、アプリケーションのアセンブリフェーズ全体の中で最も容量が大きく、技術的に複雑な部分です：静的コード分析、単体テスト、機能UIテスト、ローカリゼーション検証。
• デプロイします。 現在、アセンブリ全体から抽象化されており、横にあるようです。 したがって、必要に応じて、あらゆる環境（アルファ版、ベータ版、リリース版）のあらゆるリビジョン/ブランチ/アプリケーションのタイプにデプロイできます。

これで、原則として、あなたは物語を終えることができますが、私は、おそらく、重要性を示し、詳細を提供します。

組立

現在、1つのコードベースで3つのプロジェクトを一度に開発しています。プロジェクト1、プロジェクト2、プロジェクト3と呼びましょう。もちろん、3つの製品はすべてメールクライアントのカテゴリに属しているため、チェスとビデオプレーヤーの違いほど根本的な違いはありません。 ただし、設計が異なり、機能に違いがあり、さまざまな方法でサーバーと対話します。 これらすべてが、アセンブリ、テスト、および製品開発の要件を決定します。

機能ブランチのワークフロー

アセンブリは、バージョン管理システムからのプロジェクトリビジョンのチェックアウトから始まります。 なぜこれに注意を向けるのか-結局、誰もがチェックアウトできるのでしょうか？ 本当に。 しかし、どのブランチから価値がありますか？



製品で作業するために機能ブランチワークフローを使用します。 このアプローチについては、個別に読むことができます 。 私にとっての主な利点は、変更の分離です。 このアプローチでは、各開発者はタスクの一部として少なくともプロジェクト全体を引き継いでテストに提供でき、QAがアプリを提供した場合、テスト済みの機能コードは一般的なブランチに分類されます。 このアプローチは、一連のアクションが定義されているという事実により、リリースに入る欠陥のリスクを最小限に抑えます。最初にチェックし、次にプロジェクトのメインブランチにマージします。



これらの分離された変更を検証するには、自動テストを実行できるアセンブリが必要であり、QAチームの承認を得るために手動テストに引き渡します。 Bambooは、すぐに必要なソリューションを提供します。 これはブランチプランと呼ばれ、ビルドでメインブランチ（たとえば、alpha）が定義され、指定されたテンプレートに従って一致するすべてのブランチが機能ブランチと見なされることにあります。 ビルドプランのクローンが作成されますが、チェックアウトはビルドプランのメインビルドからではなく、このブランチから行われるという違いがあります。 こんな感じです。







ビルドプランを表示するときに、メインブランチと既存のブランチを切り替えて、すべてのローカルステータスの結果を表示できます。



分岐計画自体は、タスクへのリンクがあることを除いて同じように見えます。







このようなフローでは、ブランチは作成された瞬間から必然的に廃止され始めます。 メインブランチとの競合を早期に検出し、更新されたコードをテストするには、開発中にブランチを常に更新する必要があります。 Bambooは、プロジェクトの構築を開始する前に、これを自動的に行う方法を知っています。 競合が発生した場合、アセンブリはベイク処理されず、開発者は最初にブランチをアップグレードしてから、これらの変更をプッシュする必要があります。 その後、アセンブリの前に競合は発生せず、すべてが通常どおり続行されます。

製品フレーバー

いくつかのバリエーション、変更するリソース、コード、構成で組み立てる必要があるプロジェクトがあるとしましょう。 これを実装する方法にはいくつかのオプションがあります。 私たちは、アセンブリのすべての条件、すべての構成、およびその他の説明的な部分をビルドスクリプトに含める必要があるという事実に導かれました。 私たちの場合、 Gradleはこの問題を解決するのに理想的です。 優れたAndroidプラグインがあり、複雑なプロジェクトを構築するための標準および非標準パラメーターのほとんどを柔軟に構成できます。



積極的に使用およびサポートするビルドオプションの数を見てみましょう。







まず、3つの主要な製品フレーバー、プロジェクト1、プロジェクト2、およびプロジェクト3があります。



製品フレーバーは、製品ブランチを表しています。 ほとんどの場合、これらは異なるパッケージ、異なる署名証明書、異なるソースおよびリソースを持つ異なるアプリケーションです。 アプリケーションごとに、いくつかのビルドオプションがあります。

• debug-デバッグキーで署名し、難読化せずにデバッグできます。
• アルファ/ブランチアルファ -難読化されたアセンブリ。分析の構成、キャッシュのアセンブリ、リソース、アプリケーションで利用可能なデバッグ設定によって区別されます。
• beta corp-ログが有効になっており、デバッグモードが利用可能なベータ版。
• beta-リリースに可能な限り近いアセンブリ。分析、クラッシュのアセンブリ、ログオフ、デバッグモードが異なり、デバッグ設定はありません。
• release-アプリケーションの製品版。ほとんどすべての追加オプションがオフになり、これらのシステムの戦闘プロジェクト用に分析および統計収集が構成されます。
• ユニット/ UIテスト -マニフェストが上書きされたアセンブリ。たとえば、SMSコードを使用した自動入力テスト（承認、登録、2要素承認）に必要なSMSの読み取りを許可できます。

合計：



8ビルドタイプ* 3製品フレーバー= 24アプリケーションバリアント



なぜそんなに？ 答えようとします。 異なる環境で公開されている3つの異なる製品で解決する必要がある一般的なタスクの1つは、分析を共有することです。 また、これを行う必要があります。そうしないと、アプリケーションのアルファ版の統計情報が、プロダクションに存在する画像を歪めます。 クラッシュに関する統計を収集するには、 HockeyAppを使用します 。 その中には、異なるアセンブリオプション用の個別のプロジェクトがあります。 これにより、たとえば、Project 1のクラッシュとProject 2のクラッシュ、ベータ版のリリースバージョンなどを簡単に分離できます。



プロジェクトのbuild.gradleでは、この構成は次のとおりです。

productFlavors { project1 { ... android.buildTypes { alpha { hockeyApp { [appId: 'b45-------1b', note: project.issues, releaseType: '2'] } } beta { hockeyApp { [appId: 'c9d-------86', note: {''}, releaseType: '0'] } } publicBeta { ... } release { ... } } } project2 { ... android.buildTypes { alpha { hockeyApp { [appId: '1ac-------73', note: project.issues, releaseType: '2'] } } ... } } project3 { ... android.buildTypes { alpha { hockeyApp { [appId: 'dcd-------3c', note: project.issues, releaseType: '2'] } } ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、アセンブリオプションにさまざまな値を設定できます。 リソースとソースコードに関しては、1つの機能を除いて、ほぼ同じ原則がここで使用されます。異なるオプションのリソースをマージすることが可能です。 私たちのプロジェクトには、すべてのアプリケーションで同じリソースがあります-たとえば、手紙を書くために画面をマークします。 そのようなファイルを各リソースパッケージにコピーして個別に保持する必要がある場合、書き込み画面のレイアウトを変更する場合、3つのファイルを変更する必要があります。 幸いなことに、gradle + androidプラグインはリソースをマージできます。



これがどのように発生するかについて詳しく説明します。誰かが同じアプローチを使用して日常のタスクを解決できる可能性があります。



リソースを持つフォルダーをいくつか特定しました（これらはすべてプロジェクトのルートにあります）。

• res-アプリケーションのすべてのバリアントに共通のリソース：共通のセレクター、マークアップ、テーマ、スタイルなど。
• res_project1-プロジェクト1に固有のリソース：これには、アプリケーションで使用されるほぼすべてのグラフィック、プロジェクトの名前を含む行、特定のロゴまたはマークアップが含まれます。一般に、プロジェクト1にのみ適用されるすべて。
• res_project23-これは少し異なります。プロジェクトと交差しないが、プロジェクト2とプロジェクト3で同じリソースはすべてres _ project23パッケージに分類されます。このようなリソースのグループ化は、生産性の高いプロジェクト2とこれは、プロジェクト1とはまったく異なります。それ以外の場合、同じリソースをフォルダーres_project2およびres_project3にコピーする必要があります。
• res_ project2 -Project 2に固有のリソース：現時点では、これらは色、グラフィック、テキストです。 その他はすべて共通のパッケージに含まれています。
• res_ project3 -Project 3の場合と同様に、このアプリケーションに固有のリソースの選択のみがこのパッケージに残ります。

その結果、各ビルドオプションについて、いくつかのパッケージをマージして、アプリケーションのリソースの共通セットを取得します。

• プロジェクト1 = res + res_project1;
• プロジェクト2 = res + res_project23 + res_ project2;
• プロジェクト3 = res + res_project23 + res_ project3。

これが基本です。 より詳細なカスタマイズを行うには、たとえば、特定のリソース、テストビルドのコードなどを追加します。 ソースコードを含むクロージャ全体は次のようになります。

  sourceSets { main { manifest.srcFile 'AndroidManifest.xml' java { srcDir 'src' exclude '**/instrumentTest/**' } resources.srcDirs = ['src'] aidl.srcDirs = ['src'] renderscript.srcDirs = ['src'] res.srcDirs = ['res'] assets.srcDirs = ['assets'] } androidTest { manifest.srcFile 'src/instrumentTest/AndroidManifest.xml' java.srcDir 'src/instrumentTest/Java' } project2 { res.srcDirs = ['res_project2', 'res_project23'] java.srcDirs = ['src_common'] assets.srcDirs=['assets_ project2] manifest.srcFile 'res_ project23/AndroidManifest.xml' } project3 { res.srcDirs = ['res_project3', 'res_ project23] assets.srcDirs=['assets_project3'] java.srcDirs = ['src_project3'] manifest.srcFile 'res_ project23/AndroidManifest.xml' } project1 { res.srcDirs = ['res_project1'] java.srcDirs = ['src_common'] assets.srcDirs=['assets_project1'] manifest.srcFile 'res_project1/AndroidManifest.xml' } testingUi { manifest.srcFile 'ui_testing/AndroidManifest.xml' } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

小規模の場合はそのままです。 ビルドプロジェクトの構成で、目的の.apkを取得するために正しいタスクを実行する必要があります（たとえば、gradle assembleProject1PublicBeta）。 当然のことながら、このような多数のアセンブリオプションがある場合、それらをすべて順番に収集するのではなく、このプロセスを並列化することにしました。 合計で、アセンブリフェーズの一部として実行される6つの並行作業を受け取りました。 各作品は、製品ごとに3つの成果物を公開しています。



ここまで読んだ人には質問があると思います：プロジェクトをビルドするたびにベータ版を収集してリリースするのはなぜですか？ 質問は本当にとても興味深いです。 私たちはすぐにではなく、長い時間をかけてこの決定に至りました。 歴史的には、ベータビルドとリリースビルドは、コードが同じリビジョンまたはコントラクトを使用して別々にビルドされていました。 そして、このアプローチには多くの問題があり、最も不愉快なのは、ベータ版の公開を決めた後にアセンブリのステータスを知ることです。 マーフィーの法則によれば、もちろん、ビルドは赤くなります。 何らかの理由で。 変更が多いほど、アセンブリに悪影響を与える可能性が高くなりますが、それについては何もできません。 エラーが発生してから検出されるまでの時間間隔のみを短縮できます。 また、理想的なケースでは、共通のブランチから切り離して実行します。 プロジェクトを無視して、ベータ版またはリリース版のみをビルドし、自動化プロセスを見ると、プロセス自動化を構築するためのアプローチ全体の主要な品質指標の1つ、おそらく、できるだけ早く問題を発見する機会、そして最も重要なこととして、学ぶ前にこれらの変更がどのように一般的なブランチに入ったか。

確認する

もちろん、モバイルアプリケーションでの自動品質管理は、昨年の傾向です。 私の経験では、多くの人にとって、これは非現実的なものです。 誰もがこれについて話しているが、ほとんど誰も見たことがない。 私たちは2年間プロジェクト内でこのようなタスクに取り組んできましたが、この間、開発者が対処しなければならない微妙な点のほとんどをかなり明確に理解してきました。 これらの問題と解決策はすべて、モバイルアプリケーションにとってはかなり新しく不安定なセグメントですが、ウェブは長い間このようになっており、十分な数の標準化された解決策があります。



ほとんどの人が最初に持っている質問は、何を自動化するかです。 開発者が答えます：コードをテストし、マネージャーは機能をテストする必要があるとすぐに主張し始めます。 私はテストが両方であると信じています。



一般に、アプリケーションについて説明すると、すべてのチェックはいくつかのカテゴリに分類されます。

• 静的分析 ：このアプローチにあまり注意が払われていない理由はわかりませんが、個々のクラスではなく、プロジェクト全体に正式なルールを適用できる非常に強力なツールです。
• UnitTesting ：このクラスの開発者またはユーザーが期待するとおりにクラスが正確に機能することを確認する古き良きユニットテスト。
• UiTesting ：最終結果を確認する機能的/エンドツーエンドテスト：ユーザーに表示される内容と、ユーザーがそれをどのように使用するか。

静的解析

静的アナライザーとして、既製のソリューションを使用します。 Androidの場合、これはLintであり、最近ではAndroid固有のコード、マークアップリソース、グラフィックスなどの品質を監視できる非常に効果的なツールになりました。 とりわけ、プロジェクト内の契約に固有の独自のチェックを追加できます。 これらの契約の1つは、レイアウト関連のパラメーターをスタイルに含めないことです。 たとえば、プロパティlayout_margin \ layout_alignParentTopまたはそのようなもの。 構文の観点からは、これらのプロパティをスタイルに入れることを禁止する人はいませんが、この場合、スタイル自体はUIコンポーネントのビジュアルコンポーネントを決定するために使用されず、マークアップファイルに書き込むことができない値を格納するために使用されます。 つまり、スタイルは属性コンテナとして使用されます。 第一に、LayoutParamsはまだマークアップに関連し、第二に、これらの属性が書き込まれているタグのコントロールではなく、その親に関連しているため、これらは分離されるべき異なるものであると判断しました彼が横たわっています。



それを見ると、コードを書くためのガイド、マークアップリソースがある、多かれ少なかれ成功しているプロジェクトには、このアプリケーションに典型的なタスクを解決するためのテンプレートがあり、そのようなものがたくさんあります。 それらはコードレビューの段階で追跡され、文書化され、営業日の初めに毎回思い出されます。または、これらの願いに慣れたら、将来、誰もがそれを実現できると期待できます。 彼らが言うように、信じる人は祝福されますが、退屈な仕事をすぐに終わらせるために急いで、私自身はそれを忘れず、何も見逃さないことを知って、私は個人的にはるかに快適に働きます。 そのようなチェックを形式化し、便利なレポートを使用してアセンブリプロセスに追加する必要があり、新しいタスクを実行する心配はありません。突然、すべてのチェックをスキップしたコードが見つかります。



小切手を書くのは簡単で、楽しくさえあります。 静的チェックを追加するプロセスでは、他の問題を静的に特定する方法に関する多くのアイデアがすぐに現れます。 ガイドと公式ドキュメントはLintに役立ちます。 Android Studioでルールを直接開発できます。



tools.android.com/tips/lint-custom-rules

tools.android.com/tips/lint/writing-a-lint-check



Javaコードの場合、長い間発明された静的アナライザーもあります。 すべてをリストするのではなく、FindBugsを使用していることを伝えます。 ツールを選択したとき、便利な形式、チェックするための十分な量のルール、および独自のルールを追加する機能を取得したかったのです。 現時点では、閉じたカーソルの確認、アプリケーションコンテキストでAccountManagerインスタンスが常に取得されることの確認、イベントクラステンプレートの使用時に呼び出される必要があるonEventCompleteメソッドの呼び出しなどの必要な確認を記述しました。 内部チームの配置を決定する独自のルールを追加し、不注意による一般的なミスを防ぐことは、コードのレビューとテストの時間を短縮し、そのようなエラーが少なくとも将来的にアプリケーションの実稼働バージョンに入らないようにする素晴らしいプラクティスです。 小切手を書くためのガイドとして、 FindBugs、パート2：カスタム検出器の記述を使用しました。 独自のプラグインを作成し、検出器を追加し、検証プロセスでこれを使用する方法を明確に示しています。 レポートは、フォーマットされたHTMLドキュメントまたはXMLレポートの形式で提供されます。XMLレポートの形式では、簡潔に、場合によっては、エラーが見つかったクラス/メソッド、エラーコード、文字列などが記述されます。 これは通常、自分でクリーンアップしなかった場所を理解するのに十分です:-)。



すごいですね。 膨大なルールとよくある間違いが既に用意されています。それを補う機会があります。勇気を見つけて使い始めるだけです。



プロジェクトでSNAPSHOTバージョンのライブラリを使用していることに気づいたとき。 明らかに、これは、使用するライブラリにこれらの変更が加えられたときに、タスクのブランチでのみ許可されます。 コードがメインブランチに注がれた後、プロジェクトにはスナップショットが表示されないはずです。 この場合、理由は非常に散発的であり、これらのエラーのほとんどを特徴づけています。 タスクがテストされ、このバージョンが完了のすべての定義に達したと判断された後、開発者はライブラリをメインブランチにマージし、このライブラリの新しいバージョンを決定し、メインプロジェクトのバージョンを変更するのを忘れたので非常に満足していました。 問題は、LintもFindBugsもビルドスクリプトをテストできないことです。 さらに、これらのチェックがbuild.gradle自体に追加された場合でも、それがどこで有効で、どこで有効でないかを知る必要があります。 明らかに、これはブランチでは許可されています。ブランチではライブラリが変更されていますが、一般的なブランチに入った後は受け入れられません。 これが、git pre-receiveフックを使用して、リポジトリレベルでプロジェクトで何が起こっているかを追跡する方法です。



多くのチームが、バージョン管理システムのレベルでプロジェクトに適したルールを設定するのに時間を費やす必要がないと考えていることを知っています。「愚か者はいません。誰もリポジトリのすべてのブランチを削除しません」理由は、例えば、時間不足によるものです。 私たちにとって、これは合格段階です。もう少し時間をかける方が良いという決定に至りましたが、製品の安全性と品質には自信を持っています。 これらの目的のために、事前受信フックは非常にうまく機能します。変更が一般的なブランチに追加されていることを確認し、この一般的なブランチのHEADに不要なコードが含まれていないことを確認できます。 最良の場合、このようなチェックの存在を誰も知ることはありませんが、実践が示すように、ランダムなエラーは故意に突き刺すことを可能にするのに十分です。 Pre-receiveフックは、開発者が喜んで配置したすべての修正済みTODOおよびFIXMEをチェックするのに最適ですが、修正するのを忘れています。 また、多くの詳細を必要とする非常に複雑なバグがブランチで見つかったため、開発者が関心のあるすべての機能に新しいThrowable（）の出力を追加することで、典型的なロギングの問題に完全に対処します。 私たちにとって、ミスを追跡する能力は、同じレーキを再び踏まないことを理解するために自動的に重要です。 誰もが間違いを犯します。それはあなたがその後どのような結論を出すかだけが重要です。 私たちの結論は、修正に加えて、これらのエラーが引き続きコミットされないようにするための努力が必要であるということです。

単体テスト

ここでは、概して、すべてが当たり前です。 クラスによっては、クラスが意図したとおりに機能することを確認するためのチェックが記述されており、同時にクラスのクライアントに使用方法の例を示しています。 現時点では、単体テストは実際のデバイスで実行されますが、必要に応じて実際の接続は確立されません。 ところで、接続を確立する必要性について：開発者が特定のモジュールをテストする方法を考えるとき、ほとんどの場合、まず、現在の環境からテストを分離するためにクラスの依存関係を置き換える方法を考えます。 ネットワーク接続の場合、これは困難なタスクのように思えるかもしれません。ネットワークの相互作用は単一のメソッド呼び出しに置き換えられないため、濡れるにはロジックの層が必要です。 しばらくの間、アプリケーションコードでフックを使用してサーバーの応答を置き換え、それを使用して後続のすべてのアクションを実行することに抵抗しました。 実際、このアプローチは戦闘アプリケーションで動作するコードがテストされないというリスクを増加させるということです。 問題が発生するたびに、利便性をテストするためにクラスインターフェイスを変更する価値があるか、いくつかの依存関係を「ロックアップ」するために関数実行プロセスに追加条件を追加する価値があるか、私は次の位置を固守しようとします：まず、すべてのコードは安全であるアプリケーション機能の面で。 コードに追加された追加条件が個別のチェックを必要とする場合、これはテストには必要ありません。 これが、通常のセッターに満足しなかった主な理由です。セッターは単に答えを置き換え、別のソースからそれを取得します。



その結果、私の意見では、より正直に別の決定に至りました。 これは、テストの1つがどのように見えるかであり、特定の回答でコマンドがステータス「error_folder_not_exist」を与えることを確認します。

  @AcquireCookie @LargeTest public void testDeleteNonExistingFolder() { DeleteFolder delete = runDeleteFolder(999); assertERROR_FOLDER_NOT_EXIST(delete); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このテストでは、サーバーに対して正直な要求を行います。つまり、チームはアプリケーションとまったく同じように動作します。 問題は、単体テストが、実行中のデバイスでネットワークがどのように構成されているかに依存することです。 次に、2番目のテストを示します。これは、まったく同じことを確認しますが、実際の要求を実行したり、サーバーと対話したりすることなく、既に目的の回答を置き換えています。

  @MockMethod(response = RESPONSE_NOT_EXISTS) public void testDeleteNonExistingFolderMock() { testDeleteNonExistingFolder(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、テストの実行を制御することができます-これは、たとえば、ビルドのステータスがサーバーの応答を考慮しないようにするために必要です。 記述される対話プロトコルに依存し、要求が正しく形成されることを確認する（もちろん、単体テストを使用して）ことで、サーバーが正しい答えを返すことを確認できます。 そして、正しい答えがあれば、アプリケーションがそれに応じて解釈することを確認するためだけに残ります。 ただし、たとえば、ナイトリービルドの場合、サーバーと対話するための契約が破られないようにすることをお勧めします。 このために、実際に相互作用するテストを含むすべてのテストが開始されます。 これにより、何らかのバグが原因でサーバーとの対話の契約が​​破られた場合に備えて、追加のエアバッグが提供されます。 これについては、市場のユーザーレビューからではなく、テスト結果から学習します。 機能を最初から最後まで確認することが非常に重要な場合は、これらのテストを基本にして、アプリケーションのビルドごとに実行できます。



実際、私たちは常にサービスに依存したくありませんが、同時に状況を監視し、すべてが正常であるか、アプリケーションの一部が正常ではないという毎日のレポートの形で毎日の情報を受信する必要があります。 ここでは、完全な運用に不可欠なアプリケーションとサードパーティサービスを分離することを好みますが、私たちの責任範囲ではありません。 サードパーティのサービスの操作に関連するアプリケーションの問題を検出できますが、修正することはできません。 私たちのタスクは、問題を報告し、修正を待ち、このサービスを操作するためのテストを実行して、問題が修正されたことを確認することです。

UIテスト

ユーザーの観点から見ると、これらは最も正直なテストです。 開発者の観点から-最も複雑。 最も正直なのは、彼らが最終製品をテストしており、その一部ではないからです。 他の人に非難することはできません。バグはアプリケーションのバグであり、その原因が何であるかは関係ありません。Androidの不完全性は、別の開発者などの不正な手によるものです。 いずれにせよ、エラーを修正する必要があります。 このようなブラックボックステストの利点には、実際には、機能の実装方法、アプリケーションのアーキテクチャなどに違いはないという事実が含まれます。アプリケーションの2つのバグが重複し、その結果、ユーザーが正しい結果-これは私たちに合っています。 — .



- , , , UI- , .



. , , — . , . ( , - , - ) , . , , , . . , , , . , , , .



, , . : , . , , , , - , 99% . , , , , , , , , . , , , . , Android iOS. , , , . , , , , , , .



Robotium. , , . , . , , . , , . Espresso! , . . , . Robotium 2 , , , . . Robotium, , Sleep Pattern'. , , sleep(N * 1000) , . : , (UI Thread). , , Sleep(), . : 10 , . Instrumentation-based , , UI Thread , . android.app.Instrumentation :

  /** * Synchronously wait for the application to be idle. Can not be called * from the main application thread -- use {@link #start} to execute * instrumentation in its own thread. */ public void waitForIdleSync() { validateNotAppThread(); Idler idler = new Idler(null); mMessageQueue.addIdleHandler(idler); mThread.getHandler().post(new EmptyRunnable()); idler.waitForIdle(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, , , View , , , , View , ..



, , Espresso , . ; Google , , Espresso . Lead developer' , Robotium Espresso TestRunner. , . , , Espresso. . .



Espresso , . ~26 , . 4%. , . , , waitForIdleSync : , — , , . CustomIdlingResource Espresso Robotium. , , — idle , custom idling resource . , , , idle , , .



, Espresso — . , , , .



, , , — , . , , Sharing ( ) - . , . Robotium/Espresso- , . , , cross-app functional UI tests, UI Automator. , , Testing Support Library, Google I/O 2015, , . , , , :

1. , .
2. , , , .
3. push- .
4. , .
5. back-., , .

, , , .., 3 4 uiAutomator framework, , , , . API Espresso, . , .



, . — , .



, , , product flavors , , - .. adb, usb, VirtualBox . , , , .



PS Android- . 空室に興味がある場合は、お気軽にMaryにご連絡ください 。