2週間前、サンクトペテルブルクヤンデックスの開発プロセス自動化学校 （CAD）は終了しました。

将来を見据えて、教師は最も重要なことをしたと思います。学校の初めに約束したように、3か月も経たないうちに開発プロセスに対する認識が「損なわれ」ました。 手動テストとアセンブリはひどく迷惑になり始め、「しかし、今では、日常的な操作を実行する代わりに、美しいコードを書くことができる...」という考えを引き起こしました。



彼らがどのように成功したかについてはこちらでもっと読むことができます 。



トレーニングの実際の部分では、上記の技術に基づいたWebブログを実装しました。

Android開発者として、私はこれらのテクノロジーとツールを使用してAndroid向けの継続的インテグレーションを編成する可能性に興味がありました。

Alexey KorovyanskyのMBLTDev に関するレポート 、特にAndroidアプリケーションのテストに関するGoogle Test Automation Conference 2014の結果に触発されて 、私はトレーニングプロジェクトの簡略化された類似物を別のプラットフォームに実装し、可能な限りすべてを管理しました。 これで序文は終わり、自動化の実際の説明が始まります。

1.自動テスト

自動化とは、テストを意味します。 テストとは、自動化を意味します。

多くの場合、テストは開発プロセスの中で最もリソースを消費する部分の1つです。 ボタンのテキストは、数分（IDEの開始時間を含む）で変更でき、数分でプロジェクトを組み立てます。次に、すべてのコントロール画面解像度でこのボタンを使用して、レイアウトがすべての場所にあるかどうかを確認します。 もちろん、このプロセスが自動化されていない場合。



幸いなことに、2014年12月、GoogleはAndroidサポートリポジトリにEspressoフレームワークを含めることで、Android開発者を喜ばせました。 やった！ 最後に、オペレーティングシステムの開発者によってサポートされている、システムテストを作成するための強力でかなり安定したツールがあります（特に、テストがAndroidの新しいバージョンのリリースにまかないることを期待します）。

HabréのEspressoについてはすでに書いているので、現在のバージョンでは、テストの操作をUI ThreadおよびAsyncTasksだけでなく、 任意のバックグラウンド操作 （http-requestsなど）とも同期できるという観察に限定します。 システムと統合テストの実装の例は、記事の最後にあるリンクgithubの私のプロジェクトにあります。

2.自動アセンブリ

私たちの賢明な時代には、おそらく組立システムを使用する利点を説明する必要はありません。

CADではMavenを使用しましたが、Android StudioではGradleがサポートされているため、他の何かを使用するのは不便です。

テストを実行するために、タスクが使用されました。

• connectedAndroidTest-典型的なgradleタスクのリストから
• スプーン -適切なプラグインをインストールすると表示されます。 悪名高いジェイク・ウォートンが率いるスクエアチームの非常に有用な開発。 接続されている複数のAndroidデバイスで同時にテストを実行したり、それらからスクリーンショットを撮ったりすることができます。

3.自動テスト実行

奇跡によってMavenやGradleを使用していない場合、さらに読むことはできません-継続的な統合サーバーはプロジェクトと友達になりません。

そして、それを使用する場合、プロジェクトの数十/数百のテストを数回起動した後、これを単独で、できればプロセッサから可能な限り実行することを強く望んでいます:-)。 ここでジェンキンスは私たちの援助に来ます（TeamCity、Atlassian Bamboo、必要なものを強調します）。 CADで教えられたJenkinsを使用しました。 Jenkinsについて、またHabréのAndroidアプリケーションとの直接的な関係についても多くのことが書かれています。

私たちの場合、デフォルトのプラグインに加えて、

• GitHubプラグイン、GITプラグイン、GitHub APIプラグイン-githubからコードを受信し、イベントをインターセプトするため
• Gradleプラグイン-gradleタスクを実行します
• Android Emulator Plugin-エミュレーターでアプリケーションを実行します（このアイデアを捨てて、スプーンを使用します）
• HTML Publisherプラグイン-タスクページで任意の形式のテストを実行した結果の説明を公開するため
• JUnitプラグイン-単体テスト結果の公開用

一般に、実際のデバイスとgenymotionの仮想画像でテストを実行すると、速度、安定性、リアリズムの点でGoogleの標準Androidエミュレータよりも良い結果が得られたため、現時点ではテストでの使用を拒否しました。

4.環境の分離に関するいくつかの言葉

たとえば、テスト用と実稼働用に異なるデータベースを使用することについて話します。 これを行うには、さまざまな設定をコードに変換する必要があります。 モデルプロジェクトでは、これはgradleビルドフレーバーを使用して実装され、変数は定数を持つ別のファイルに移動され、プラグインが目的のアセンブリに置き換えます。



したがって、モデルAndroidアプリケーションの部分的に自動化された開発プロセスは、現時点ではどのようになっていますか：

1.書かれたコードはgithubに送られます。

2. Jenkinsはgithubでフックをキャッチし、サーバー/ノードで実行/接続されているすべてのAndroidデバイスでビルドを開始します

3.アセンブリの結果に応じて、ジェンキンスはgithubへの登録解除/開発者への手紙の送信/ドアの上に赤または緑のライトを点灯（必要に応じて下線を引く）

4.アセンブリが成功した場合、インストールファイルがテストデバイスにアップロードされ、ハンドブレーキテスターに​​（必要に応じて）作業を開始できることが通知されます。

5. Google Play Android Publisherプラグインを使用して、組み立てたプロジェクトをGooglePlayに自動的に公開することも可能です



TODO ：残念ながら、私はまだSonarQubeを上げることができませんでしたが、CADではコード分析ツールの有用性と重要性を視覚的に評価することができました。 はい。テストプロジェクトのコードカバレッジはまだ考慮されていません。 十分にテストされたコードを書くのに非常に便利な依存性注入メカニズムを使用することはできませんでした-Androidにはこのための素晴らしいDaggerライブラリがあります。 一般に、まだやるべきことがあります。



モデルプロジェクト （投稿/コメントを追加/削除する機能を備えたブログ） への約束されたリンクと、それに対する多数のテスト。 コードをあまりにも厳しく判断しないでください。テストするのが理にかなっているために、ときどき壊れるはずですよね？ ;-)



プロジェクトはライブラリを使用しました：

• ロボスパイス
• 後付けとokhttp
• androidannotations
• 食器棚
• そしてもちろんエスプレッソ

この機会を利用して、CADおよびYandexの講師全般に心から感謝します。

もう一度世界を少し良くしました。 よろしくお願いします！ :-)