その1の2日目の記事ですこんにちは。SWETの加瀬(@Kesin11)です。LabはiOSとAndroidに対応した実際の実機デバイス上でテストを実行してくれるサービスです1。Labが将来的にiOSをサポートするかどうかという話はこれまで何もありませんでした。LabのiOS版が発表されたとき個人的には大興奮でした。LabにあるiOS実機でXCTest、XCUITestを実行してくれて、デバイスごとのテスト結果や動画などを確認できます。LabのiOS版について、以下の複数の利用方法についてそれぞれ解説していきます。Bitriseから使うgcloudコマンドから使う(ローカル)gcloudコマンドから使う(CI環境)Fastlaneプラグインから使うなお、本記事の動作確認はこちらのリポジトリをベースにXCTestを追加し、XCUITestを少し修正したものを使用しています。使用したXcodeのバージョンは10.1です。https://github.com/browserstack/xcuitest-sample-browserstackBitriseから使うBitriseはモバイルアプリに特化したCI/CDサービスです。Bitriseをお使いであれば、現状ではこの方法が最も簡単、かつ無料の方法になります。Testingというステップが存在します。これは名前の通りに実機デバイスでXCTest、XCUITestを実行し、テスト結果だけではなくてそのときのスクリーンショット、動画、デバイスログも保存してくれるものです。Labを使用していることが公式に解説されています。Labは本来アカウントの認証が必要であったり、一定以上の使用には課金が必要です(認証と料金については後述)。Testingを使用する場合にはFirebaseとのやりとりをBitriseがやってくれるため、アカウントの認証不要、さらに現在はβ版のためか無料で使うことができます。Testingのステップから確認できます。執筆時点での一覧はこのようになっていました。6が存在し、多少ですがiPadも種類が用意されています。9.0からそろっています。iOSバージョンの実機を実際に手元で用意、管理するのはなかなか大変だと思います。これこそが、この手のサービスで最も嬉しいポイントではないでしょうか。Testingのさらに詳しい使い方やスクリーンショットは、Bitrise公式のドキュメントやブログが充実していますので、そちらを見てもらうと分かりやすいと思います。Labを使う方法になります。Labを使うにはアカウントの認証と、紐付けるプロジェクトの選択が必要になります。PROJECT_IDを実行してください。PROJECT_IDはfirebaseのプロジェクトIDです。firebaseのプロジェクトを作成していない場合、先にfirebaseのプロジェクトを作成しておいてください2。gcloudコマンドのセットアップができたら、まずは使用できるデバイスの一覧を見てみましょう。Bitriseと同じリストが表示されましたね。次にテスト用のビルドを作成します。ドキュメントにあるようにxcodebuildでビルドします。アプリ名とスキームがMyAppで、ビルド結果の出力先をfirebase_testとした場合には以下のようなコマンドになります。Labでテストを実行するには、テスト用のビルド成果物とxctestrunファイルを1つのzipに圧縮する必要があります。MyApp_iphoneos12.1-arm64e.xctestrunあるいはFastlaneを導入済みならばscanのbuild_for_testingオプションを使ってテスト用ビルドを生成しても大丈夫です。true)テスト用のビルドができたらいよいよテストを実行してみましょう。--xcode-version=10.1テストを実行したいデバイスの設定を--deviceの引数に渡します。modelとversionには先ほどのモデル一覧で表示されたMODEL_IDとOS_VERSION_IDSを指定します。必要であればlocaleとorientationも指定可能で、指定しなかった場合のデフォルトはenとportraitとなります。listで一覧の確認が可能です。Lab側でテストを実行するXcodeのバージョンのようです。10.1でビルドした場合に--xcode_versionの指定無しでも動くことを確認しましたが、古いXcodeを使用している場合や、新しいXcodeが出た直後などにはバージョンを指定しておいた方がいいかもしれません。Labのページで結果を見ることができます。実行が完了するとこのように複数のデバイスでテストケースごとのテスト結果、スクリーンショットや動画を確認できます。Labを実行をできるようにしておくのがよいでしょう。iosを実行するにはアカウントの認証が必要です。認証にはブラウザでログインする必要があるので通常の方法ではCI環境で認証することはできず、テストを実行できません。この問題はサービスアカウントを使って認証することで解決できます。この方法に関してのドキュメントはAndroid版の方に一応存在するのですが、あまり分かりやすいとは言えないため解説します。サービスアカウントによる認証まずはGCPのコンソールからサービスアカウントを作成します。https://console.cloud.google.com/iam-admin/serviceaccounts/サービスアカウントの権限には「プロジェクトの編集者」の権限を付ける必要があります。権限の設定が完了したら最後にjson形式で鍵を生成してください。APIを検索し、両方とも有効化してください3。jsonの鍵を用意できたらgcloudコマンドがサービスアカウントを使うように認証させます。listを実行してサービスアカウントにACTIVEが付いていればOKです。runを実行して、まずはローカルの環境で実行できることを確認しておきましょう。Labを実行するときにエラーとなってしまう場合があるようです。https://stackoverflow.com/questions/48327027/cant-run-firebase-test-lab-tests-using-gcloud-and-service-account-403-does-no?rq=1上記のベストアンサーではない方の回答に、Firebaseのサービスアカウントの鍵を使うと動作したという回答がありました。Firebaseのサービスアカウントの鍵は以下のurlからアクセスできるページで作成できます。https://console.firebase.google.com/u/0/project/FIREBASE_PROJECT_ID/settings/serviceaccounts/adminsdk(FIREBASE_PROJECT_IDのところは自分のプロジェクトidに書き換えてアクセスしてください)自分が試したところ、たしかに動作することを確認しました。詳しい理由は不明ですが、自分と同じようにGCPで作成したサービスアカウントではどうしてもエラーになってしまう場合に試してみるといいかもしれません。CIサービスのビルドフローの設定サービスアカウントの認証ができたところで、次はCIサービスのビルドフローに組み込んでみましょう。お使いのCIサービスでgcloudコマンドを使えるようにし、先ほどと同様にサービスアカウントで認証をしてからテストを実行するフローを構築してください。注意が必要なのは、サービスアカウントの鍵のjsonです。チームの体制にもよりますが、一般的にはリポジトリにコミットするべきではないでしょう。使用するCIの環境によっては秘密にしておきたいファイルをリポジトリとは別に登録するという方法ができない場合もあるかと思います。そのような場合は、CircleCIのドキュメントにあるようにjsonの中身を環境変数として登録しておき、ビルドフローの中で再度jsonとして書き出すという方法が使えます。CircleCI実際のサンプルとしてBitriseでgcloudを使ってサービスアカウントの認証、テストを実行する方法を紹介します。サービスアカウントの鍵であるjsonの中身をcatとpbcopyなどを使って丸ごとコピーして環境変数にセットしておきます。以下のコードでは$SERVICE_ACCOUNT_KEYで参照しています。BitriseのScriptステップはシェルスクリプトをそのまま実行できるため、ここでインストールから認証まで行います。runを実行するだけです。テスト用のビルドについては説明済みですので、今回は省略します。model=iphone6s,version=10.3,locale=ja_JP,orientation=landscape上記のサンプルには主にgcloudコマンドをセットアップするBitrise特有のコードも含まれてしまっていますが、サービスアカウントで認証してテストを実行する部分は他のCI環境でも同様に動作すると思います。CircleCIの組み合わせの記事を探してみるのがよいでしょう。Labを実行するFastlaneプラグインを使用するという選択肢もあります。fastlane/fastlane-plugin-firebase_test_lab使い方はREADMEに書いてあるように、scanでテスト用のビルドを行ってからfirebase_test_lab_ios_xctestでテストを実行します。注意点として、READMEのサンプルをそのまま使用した場合はgcloudのデフォルトの認証情報が使われます。gcloudのコマンドから実行したときと同様に、CI環境では動きません。oauth_key_file_pathというオプションにサービスアカウントの鍵のパスを指定することで、サービスアカウントで認証を行うことができます。])ただし注意点として、FastlaneのプラグインはコミュニティによってメンテされているためXcodeのバージョンが上がった場合などに動かなくなる可能性があります。10.1でxctestrunの形式が微妙に変わったことで動かなくなってしまったバグの修正PRがついこの前マージされたようです。このように何かがバージョンアップされた場合に壊れてしまうリスクがあるということは覚えておいた方がいいでしょう。最後は気になるお値段の方ですね。Blogなどをウォッチしておくといいでしょう。Labを使用する場合は無料プランと、従量課金プランがあります。Planの場合はテスト5回/日のようです。チームの規模が大きい場合には全てのpull-reqごとに実行するような使い方は難しいと思いますので、テストを実行するブランチを絞ったり、深夜ビルドでのみ実行するといった工夫が必要かもしれません。Planにした場合、回数の上限はなくなり$5/デバイス/時間となります。これの意味するところは、テストを実行したデバイス全ての稼働時間の合計が1時間につき$5という意味です。具体的な例としては、1回の実行に12分かかるテストを5台のデバイスで実行した場合、合計で1時間=$5と計算されるということになります。Deviceのみとなります。上記の料金の計算は執筆時点(2018年12月)のドキュメントを参考にしたものであり、必ずしも正しいことを保証するものではありません。Firebaseの料金は今後変化する可能性がありますので詳しくはFirebaseの料金のページを参照するようにしてください。Labによる実機テストを行う方法の解説をしました。Labはとても簡単に使えて、無料プランもあるのでこの手のサービスの中ではかなり試しやすいサービスだと思います。ビルドのたびに様々なiOSデバイス、iOSバージョンの実機で自動テストを実行することが理想ですが、人手を介さずにそれを全自動で行ってくれるシステムを構築・運用することはとても難しいです。Labを使って、ゼロ円から実機の自動テストを始めてみませんか?Android版では実機だけではなくエミュレータを使用してテストを実行することも可能です。実はGCPのプロジェクトIDでも実行することは可能ですが、テスト結果画面を見るにはFirebaseのプロジェクトページにアクセスする必要があるため、どのみちGCPのプロジェクトに紐づけたFirebaseのプロジェクトを作成する必要があります。いうように有効化するか尋ねられるので、そこでyesとしても大丈夫なようです。2days開催レポートはじめまして、SWETの井口(@hisa9chi)です。Buildとは一体何者なのかこんにちは。SWETの加瀬(@Kesin11)です。(1)リンクプライバシーポリシースターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。