1 of 23

FlankでE2Eテストの可能性を最大限に引き出す

April 20th, 2021

Android Test Online #1 - connpass

🙏 @mhidaka 🙏 @tahia910 🙏

2 of 23

EN: https://bit.ly/ato-flank-en�JP: https://bit.ly/ato-flank-jp�

https://github.com/pgreze/

https://twitter.com/p_greze

https://pgreze.dev

Slides

Blog

3 of 23

Firebase Test Lab?

https://firebase.google.com/docs/test-lab

Supports:

Android のインストルメンテーションテスト (Espresso)
Android の Robo テスト（ノーコード）
iOS と Android のゲームループテスト
iOS の XCTest

4 of 23

5 of 23

Test Labプランの種類

	Spark プラン(無料)	Blaze プラン(従量制)
無料枠	仮想デバイス: １０件/日物理デバイス : ５件/日	仮想デバイス: ６０分/日物理デバイス : ３０分/日
追加料金	利用不可（上限）	仮想デバイス: $１/デバイス/時間物理デバイス: $５/デバイス/時間

Test Labは、２つの種類(しゅるい)のプランがあります。

Sparkプランは、基本的に無料で使えます。

仮想（かそう）デバイスは1日(いちにち)当たり10件で、

物理（ぶつり）デバイスは1日(いちにち)当たり５件が無料です。

無料枠には限度（げんど）があるので、追加料金が発生（はっせい）せず、安心（あんしん）して使えます。

しかし、それ以上使いたい場合、他(ほか)のプランに変更する必要があります。

Blazeプランでは、Spark プランより無料枠（むりょうわく）の条件（じょうけん）がいいです。

一日当たりに使える量（りょう）がおおいです。

料金について言えば、

1つの仮想（かそう）デバイスで１時間当たり１ドルで、

1つの物理（ぶつり）デバイスで１時間当たり５ドルです。

従量制　じゅうりょうせい　measured rate system; cost charged by quantity

有料枠（ゆうりょうわく）

6 of 23

どうやったらTest Labが使える？

アプリのAPK＋テスト用のAPKを事前に用意する:

./gradlew app:assembleDebug \ // -> app-debug-unaligned.apk� app:assembleDebugAndroidTest // -> app-debug-test-unaligned.apk

7 of 23

テスト実行時の制限

テストは順次実行される�
gcloud に依存

Pythonに依存
多機能なため頻繁な更新がある

8 of 23

And here is coming Flank��そこでFlankの登場です

9 of 23

Flank

テストシャーディング(= 並列実行)
gcloudのYAML設定と互換性
コストレポート
安定性テスト
HTMLレポート
JUnit XML

https://flank.github.io/flank/

10 of 23

FlankのAndroidテスティング内部構造

11 of 23

どうやったらFlankが使える？

最新版のflank.jarをダウンロードしてコマンドラインから実行: �https://github.com/Flank/flank/releases/latest

12 of 23

Flank設定（テストを８並列で実行する場合）

gcloud:

app: ./app-debug.apk

test: ./app-debug-androidTest.apk

device:

- model: NexusLowRes

version: 28

flank:

max-test-shards: 8

13 of 23

Flank実行時の紹介

14 of 23

<- gcloud

Flank ->

15 of 23

16 of 23

Gradleでも利用可能 github.com/runningcode/fladle

17 of 23

Github Actionsでも利用可能 (NEW!!)

18 of 23

シャーディングの課題

依存があるテストの例

ユーザーAがテスト１にログインしていて、
同じユーザーAを使うテスト2を実行した場合、
テスト１に通知が出て、テストが壊れてしまう 😭�

スケーラビリティが必要なテスト環境

たくさんのリクエストがあり並列性の高いdev環境�

Test Labでの待ち状態(“inconclusive” shards)

デバイス不足により発生する可能性がある

しかし⬇️、完全（かんぜん）に魔法（まほう）という⬇️わけではないので⬇️、

気をつけなきゃいけないこ⬆️ともあります⬇️。

たとえば、同じユーザーで⬇️ログインが必要なテストが

並列（へいれつ）で動（うご）く場合（ばあい）です。

ある⬇️テストにログインをしていたら、

同時（どうじ）に同じユーザーでログインしているテストに依存（いぞん）がうまれてしまって、

落(お)ちることがあります。

あとは、たくさんのリクエストがきますので、サーバーへの負担（ふたん）が⬆️大きくなります。

スケーラビリティも配慮（はいりょ）するべきです。

そして⏭、もし現在（げんざい）使用（しよう）可能（かのう）デバイスの数が足（た）りなかったら、

待ち時間が発生（はっせい）してしまいます。

それで⏭、もし待ち時間が長⬆️すぎたら⬇️、

タイムアウト扱（あつ⬆️かい）になって、

flankが止まって、リクエストが⚠️キャンセル⚠️されて、

inconclusiveというエラーメッセージが表示されます。

19 of 23

タイムアウトによる中断の原因

それぞれのテスト�
デバイス (設定ファイルのgcloud.timeout)

物理デバイスでは最大45分
仮想デバイスでは最大60分�

Flank (設定ファイルのflank.run-timeout)

デフォルトは無限待ち�

利用しているCIの設定

例: CircleCI 5 時間でタイムアウト

タイムアウトによる⬇️中断（ちゅうだん）の原因（げんいん）は、いくつかあります。

それぞれのテストにとって、はやめにおかしい実行（じっこう）を⚠️キャンセル⚠️するため、

⚠️タイムアウト⚠️があります。

テストラボ⚠️にとって↪️、デバイスの⚠️タイムアウト⚠️もあります⬆️。

設定ファイルにgcloud.timeoutで変更することができるけど⬆️、

デバイスタイプによって↪️、タイムアウト⚠️の最大値（さいだいち）にも気をつけてください。

たとえば、物理（ぶつり）デバイスなら、最大（さいだい）４５分です。

そして⏭、無限（むげん）待ちを避（さ）けるため、flankの⚠️タイムアウト⚠️もありますけど⬇️、

実は、シーアイによって⏭、⚠️デフォルト⚠️のタイムアウトも⬆️あります⏭。

flankやシーアイの⚠️タイムアウト⚠️が起きたら、inconclusiveというエラー⚠️メッセージ⚠️が表示されます。

物理・ぶつり

仮想・かそう

最大・さいだい

中断（ちゅうだん）

20 of 23

Smart flank

flank:

# the amount of groups to split the test suite into� max-test-shards: 100

# the amount of time tests within a shard should take (分で)� shard-time: 120

smart-flank-gcs-path: ./last-JUnitReport.xml

Smart execution logs
実際の実行は約8分30秒、プロビジョニングなどの手順は考慮されていません

10分

3分

10分

3分

Before:

After:

21 of 23

Add new features

FlankはKotlinで書かれているのでCoroutinesなどを使った拡張も容易 🙌�
例：mercari/flank/pull/8

22 of 23

Feature request: 使いやすいHTMLレポートが欲しい

日本語が含まれているとレポートが壊れてしまう
exceptionしか表示されない

23 of 23

ありがとうございました :)

もし興味があれば:

オートメーションとテストインフラを使った業務
FlankやKotlin Scriptといった面白い技術スタック
仕事仲間を募集中：Software Engineer, Tool and Infrastructure

参考