やらなイカ?

たぶん、iOS/Androidアプリの開発・テスト関係。

UWA GOT v2.0.2でAndroidのIL2CPP・ARM64に対応された模様

Unity向けプロファイリングツールであるUWA GOTのv2.0.2がリリースされていました*1。 追加機能として書かれているのはAndroidおよびWindowsプラットフォームでのIL2CPPビルドとAndroidプラットフォームでのARM64対応ですが、細かい使い勝手の向上も入っていたので、あわせて紹介します。

UWA GOTの導入については、過去記事を参照してください。

www.nowsprinting.com

www.nowsprinting.com

AndroidのIL2CPP・ARM64に対応

これまで、AndroidプラットフォームでUWA GOTを有効にするには、スクリプティングバックエンドにMonoを選択する必要がありました。 v2.0.2からは、IL2CPPを選択してビルドしてもUWA GOTが有効になります。また、ターゲットアーキテクチャにARM64を選択しても同様に有効になります。

ただし、IL2CPPビルドではプロファイリング項目の"Mono"テストモードで採取できません。 Monoテストモードでは、ヒープを多く使用しているメソッドやメモリリークの疑いのある関数を探すことができます。こちらを利用したい場合には、スクリプティングバックエンドをMonoに変更してビルドする必要があります。

複数プラットフォームの切り替えが楽になった

v2.0.1までは、以下の理由からプラットフォーム切り替えごとにUWA GOTのSDKをプロジェクトから削除してインポートしなおすことが必要でした。

  • 最初のSceneに配置するprefabのファイルがプラットフォームによって異なる
  • dllの中に同名のシンボルが存在する

これがv2.0.2では解消し、あらかじめ複数のプラットフォーム向けSDKをインポートしておいて、以降は普段通りSwitch Platformで切り替えることができます。

スクリーンショットのアップロードを抑止できるようになった

プロファイリングに必要な各種データとともにスクリーンショットを確認できるのはUWA GOTの良いところなのですが、IPモノを扱っている場合は逆に使いにくいという話も聞きます。

v2.0.2では、採取した計測データをオンラインサービスにアップロードするタイミングで、これを抑止する選択肢が追加されました。

下図は、AndroidのUWA GOT Appで計測データをアップロードする画面です。「スクリーンショットをGOT Onlineにアップロードします」のチェックをoffにすることで、オンラインサービスにはスクリーンショットなしのデータが送られます*2

f:id:nowsprinting:20200221092627p:plain

なお、このチェックボックスが機能するのはオンライン向けのアップロードのみであり、Unityエディタ上で動作するローカルサーバへのアップロードは強制的にスクリーンショットありで送られます。

ローカルサーバに送られた計測データは、そこからさらにオンラインにアップロードすることができます。このとき、下図のようにスクリーンショットの送信有無を指定できます*3

f:id:nowsprinting:20200221094228p:plain

まとめ

今回のアップデートでかなり使い勝手が改善された感じです。日本でももっと流行るといいなと思っています。

*1:日付は2019/12/27。なんのアナウンスもなかったので気づきませんでした

*2:ただし、パケットキャプチャして確認したわけではないので保証の限りではありません

*3:これもパケットキャプチャして確認したわけではありません

UWA GOTでUnityアプリのプロファイリング(Android編)

UWA*1 GOT*2は、Unityアプリのプロファイリングを行なう商用ツールです。 CEDEC 2019のセッション『あなたのモバイルゲーム開発の最適化時間を数ヶ月節約する方法』で紹介されました。

セッション後にUWAのブースやメール*3で問い合わせた内容も含め、簡単な使い方をまとめます。

jp.uwa4d.com

UWA GOTは、Unity 4.6以降で使用できます。ただし、後述のUWA GOT オンラインを利用する場合は、Unity 5.6以上が推奨とのこと。

プロファイリング対象プラットフォームは、CEDEC 2019時点のv2.0.0ではAndroid (Mono)とWindows (Mono)でしたが、最近リリースされたv2.0.1でiOS (IL2CPP)も対象となりました*4

プロファイリングは、以下の流れで行ないます。

  1. プラグインを組み込んでビルドしたアプリを端末にインストール
  2. アプリを実行・計測し、別の専用アプリでデータをプロファイラ(ローカルとオンラインの2種類から選択できます)に送信
  3. プロファイラで測定データを表示し、性能ボトルネックを調査

計測をアプリ単体で行なうことができるため、テスター・デバッガの手で実行することができます。反面、現状どうしても手作業が必要になるため、デバイスファーム等で大量の自動テストを実行しながらプロファイリングを行なうようなユースケースには向きません*5

UWA GOTの構成

構成要素がいくつかありますので、先に説明します。

GOT SDK

UWA GOT公式サイトからダウンロードできます。プラットフォームごとにunitypackageが分かれており、いずれかをインポートします。内容は以下。

  • GOT Editor: Unityエディタ拡張。2つの機能を持っています
    • 対象アプリへのGOTプラグインのインテグレーションサポート
    • ローカルサーバ機能
  • GOT プラグイン: 各プラットフォーム向けのプラグイン
  • ドキュメント: 少々古いものなので、ドキュメントは公式サイトからダウンロードできる日本語版を参照

GOT App

計測結果をプロファイラ(ビューア)にアップロードするためのアプリで、Android版とWindows版がzipに同梱されています。計測対象アプリとともに端末にインストールする必要があります。

iOSではプラグインにデータ送信機能が備わっているため、GOT Appは必要ありません。

GOT ローカルサーバ(ローカルテストツール)

Unityエディタ上で動作します。アプリで計測したプロファイリングデータを受信し、表示を行なうビューアです。

GOT オンライン

オンラインでプロファイリング表示を行なうサービスです。 ローカルサーバでのプロファイリング表示に比べ、表示できる項目が多く、また他のアプリの実測値をもとにしたサジェスト機能もあります。

料金体系

ローカルサーバは、使用するマシン1台ごとに¥11,500/年。15日間のトライアルが可能です。

オンラインは、計測データをアップロードできる時間(アプリの実行時間)に対する課金で、¥5,000/時間。 トライアルはありませんが、公式サイトでデモデータを閲覧できます*6

プラグインを組み込むアプリ数、アプリをインストールする端末数、計測回数および時間に制限はありません。

利用手順

まず、UWAのWebサイトで ログイン > 新規登録 から、新規ユーザ登録を行ないます。確認メールが届くまで数分かかります。 ログインできたら、ダウンロードページからSDKと日本語マニュアルをダウンロードできます。

以下、マニュアルを参照してください。以下、わかりにくいところだけ説明します。

SDKインテグレーション

  • ライセンスキーは購入*7後、Webサイト右上のアイコン > アカウント設定 > アカウントの残額 ページの「購入済ライセンス」に表示されます。メールで送られたりしませんのでご注意ください
  • アカウントの残額 ページでは、ライセンスと開発マシンの紐付けを解除して別のマシンに付け替えることも可能です。解除しようとすると「以下のライセンスとアカウントの紐付き関係を解除しますが、操作の取り消しできないため、継続しますか?」というメッセージが表示されますが、オンライン認証であれば特に制限なく解除・付け替え可能とのことです
  • UWA/Prefabs/UWA_AndroidもしくはUWA_IOSを最初に開くSceneのヒエラルキに追加するように書かれていますが、APIでも初期化が可能です。[RuntimeInitializeOnLoadMethod]アトリビュートを付けたメソッドからUWAEngine.StaticInit()を呼び出せば実現できます。APIについてはマニュアルの付録に記載があります
  • GOT Editor > "SDK インテグレーション" > "Build here"でビルドできますが、前提条件を満たしていれば普通にPlayerのビルドを行ってもUWA GOTが組み込まれたビルドとなります
  • ビルドに何らかの原因で失敗しても特にダイアログ等が出るわけではないので、コンソールを見る必要があります
  • UnityエディタのPlayモードではプロファイリングは実行できません
  • デフォルトのビルド出力先UWA_Builds/と、プロファイルデータ格納先TestData/をバージョン管理のトラッキングから外しておくのがいいでしょう
  • Androidでは、デバイスのファイルアクセスを許可する必要があります。v2.0.1ではアプリ起動時にダイアログが出ますが、v2.0.0では設定画面かadbコマンドで許可する必要があります

計測

UWA GOTをバンドルしたアプリを起動すると、下図のGUIがオーバーレイされます。

f:id:nowsprinting:20191025071100p:plain

"Overview", "Mono", "Assets"いずれかをタップすると計測がはじまります。ボタンによって採取できるプロファイルが異なります(後述)。

"Direct Mode"は、onにするとアプリが終了し、再起動するところから計測を開始できます。offのときは、"Overview", "Mono", "Assets"いずれかをタップしたタイミングで計測を開始します。

計測が開始されると"Stop"ボタンが表示されるので、一通り動作させたらこれをタップして計測を終了します。 一度計測を行ったら、アプリを再起動しなければ次の(他の)計測はできません*8

計測データのアップロード

計測データは端末に保存されますので、UWA GOT Appを起動してアップロードします。

f:id:nowsprinting:20191025071124p:plain:w400

"UWAローカルサーバ"は、Unityエディタ上でGOT Editorを開き、"WIFI"ボタンをクリックすると起動します(IPアドレスが表示されます)。 ローカルサーバを起動した状態でGOT AppにIPアドレスを入力(ポート番号は不要)し、"チェックする"をタップします。問題なければ左のマークが緑色になります。

"自分のデータ"の下に計測したデータが並びますので、アップロード先の"Online"もしくは"Local Server"をタップ、最後に"データ提出"をタップするとアップロードできます。

なお、ローカルサーバに上げたデータをGOT Editorからオンラインにアップロードすることもできます。

計測データの表示

GOT Editorの"Overview", "Mono", "Assets"いずれかをクリックするとウィンドウが開くので、右上の"バージョン"でアップロードした計測データを選択します。

f:id:nowsprinting:20191025071430p:plain:w400

f:id:nowsprinting:20191025073622p:plain:w400

"Overview"では、"ファンクション"でCPU, FPS, MonoHeap, Hardware, markerを切り替えて表示できます。

それぞれの数値のグラフ表示、選択した場所(上図の赤い縦線のところ)のスクリーンショット*9、また、メソッド単位でヒープ使用量やオブジェクトカウントの表示*10などが便利な点です。

また、オンライン版では、DrawCall*11Canvas Batching*12なども表示できます。

*1:ゆーわ: 会社名

*2:ごーと: Game Optimization Toolkitの略

*3:UWA Technologiesは中国の会社ですが、日本に代理店があるので日本語で質問できます

*4:AndroidWindowsは引き続きMonoのみですが、近日中にIL2CPP対応されるとのこと

*5:大量のプロファイリングを行ないたい場合は、同じくCEDEC 2019のセッション『Android向けUnity製ゲーム最適化のためのCI/CDと連携した自動プロファイリングシステム』の方式が向いていそうです

*6:プロジェクト > Overview等 > デモプロジェクトを選択。オペレーション列の[確認]クリックで詳細を見ることができます

*7:PayPalで購入できます

*8:改善要望はしており、修正予定はあるそうです

*9:30fpsで撮られていますが、アプリ実行に遅延を感じること無く高速に撮影されているようです

*10:数値は10フレームごとの最大値を出しているそうです

*11:Overview > レンダリングモジュール

*12:Overview > UIモジュール

Unity Test RunnerのPlay Mode testsを実機上で実行する #UniteTokyo

9/25, 26に開催されたUnite Tokyo 2019の『Unity Test Runnerを活用して内部品質を向上しよう』というセッションの中で、テストはPlayer(Android端末など)でも実行できる旨をきちんとお伝えできていませんでした*1

以下の質問をいただいたので、これに回答する形でまとめます。

なお、本セッションのスライドはすでにUnity Learning Materialsで公開中。動画は後日公開される予定です。

learning.unity3d.jp togetter.com

セッション全体のフォローアップ記事はこちら。

www.nowsprinting.com

ネイティブプラグイン自体のテストについて

いきなりオフトピですが、ネイティブプラグイン自体のテストは、C++であればGoogletestXcodeを使ってC++のレイヤでユニットテストを書くべきです。

以下に紹介する、Unity Test RunnerのPlay Mode tests実機実行は素早く実行できるものではなく*2、Unityプロジェクトとのインテグレーション(結合・統合)を確認するためのテストケースだけに留めておくのが賢明です。

Play Mode testsをPlayer(実機)で実行する

Test Runnerウィンドウ

Play Mode testsは、Player(実機)で実行することができます。逆に言うと、Edit Mode testsは実行できません。しかし、すべてのテストを実機で実行する必要はないはずですので、一般的なロジックのテストはEdit Modeで、特別に実機でも動作させたいテスト*3のみPlay Modeで書くことをおすすめします。

ビルドターゲットを"Android"に切り替えた状態でTest RunnerウィンドウのPlayModeタブを開くと、右上に "Run all in player(Android)" と書かれたボタンが表示されます。 Android端末をUSB接続した状態でこのボタンをクリックすると、すべてのPlay ModeテストがAndroid端末上で実行されます*4

f:id:nowsprinting:20191001091335p:plain

コマンドライン

コマンドラインからのテスト実行では、引数-testPlatformに(playmodeの代わりに)実行するBuildTarget文字列を指定することで実行できます。

特定プラットフォームでのみ実行されるテスト

「このテストコードは特定のプラットフォームでのみ実行したい」というケースがあるはずです。 その場合、テストメソッドに[UnityPlatform()] アトリビュートを付与し、引数にRuntimePlatformを指定できます。

下例の場合、Test RunnerウィンドウではPlay Modeで”Run all in player(Android)”をクリックしたときのみ、コマンドラインでは引数に-testPlatform Androidを指定したときのみ実行されます。

/// <summary>
/// Android playerでのみ実行されるテスト
/// </summary>
[Test]
[UnityPlatform(RuntimePlatform.Android)]
public void RunOnlyAndroid()
{
    var platform = Application.platform;
    Assert.That(platform, Is.EqualTo(RuntimePlatform.Android));
}

なお、[UnityPlatform]アトリビュートに指定するのは、RuntimePlatformです。 コマンドライン引数-testPlatformに指定するBuildTargetとは文字列が異なるものもありますので注意してください。

iOS Playerの場合

今回Androidを例にしました。iOSの場合、例の如くXcodeプロジェクトが生成されてXcodeが起動します。このときiOS端末がUSB接続されていれば、そのまま自動でインストール・実行されます。

ただし、iOS端末は開発機としてUDIDが登録されているもので、Unityプロジェクト側にTeam IDが設定されている必要があります(要するに普通にXcodeでアプリをBuild and Runできるようにしておく必要があります)。 [1/14追記]

*1:スライドp.34には「Player(実機)」とだけ書いてありましたが特に触れなかった模様

*2:Play Mode testsが遅いだけでなく、実機で動作させるためのビルドが行われます

*3:ネイティブプラグインのほか、パフォーマンス計測など

*4:以前はUnityエディタを起動しているPCとAndroid端末が同じLAN(セグメント)に接続されていなければテスト実行結果がTest Runnerウィンドウに反映されなかったはずですが、Unity 2018.4ではUSB接続だけで反映されました

Android Test Night #5 Androidテスト全書の回 に行ってきました #android_test_night

11月に一般販売が始まった『Androidテスト全書』の著者さん達によるトーク回ということで、年甲斐もなく「ブログ・Qiita枠」で申し込んで参加してきました。

testnight.connpass.com

Androidテスト全書』は、技術書クラウドファンディングPEAKSで企画・制作されたAndroidアプリのテスト自動化を中心とした書籍で、11月初旬より製本版の一般販売が開始され、15日で限定セール分が完売してしまったという人気の書籍です。 セールは終わっていますが、製本版・電子版とも下記ページから購入できます。

Androidテスト全書

Androidテスト全書

  • 著者: 白山 文彦,外山 純生,平田 敏之,菊池 紘,堀江 亮介,
  • 製本版,電子版
  • PEAKSで購入する

本書はざっと通読しており、特に以下の観点でおすすめできる書籍です。

  • 自動テストの書き方にとどまらず、なぜテストを書くべきなのかといった、「手段」から一歩引いたところから丁寧に書かれている
  • JUnit、Mockitoといった基本的なテスティングフレームワークによる基本的なテストの書きかただけでなく、非同期、RxJavaなどに対するテストの書きかたも押さえられている
  • UIテストに関して、Espresso、Appiumそれぞれにページが割かれ、差別化されている
  • CI/CDの導入も丁寧にかかれており、Firebase Test Labにも言及されている
  • JUnit 5への移行、Local Unit TestとInstrumentation Testの統合(Jetpackへの統合)など、少し先にこうなっていくという事項にも言及されている

トークセッション

本会は、SFにいる白山さん(冒頭にビデオレターで登場)以外の著者の方々と、編集の日高さんによるトークで進行されました。

著者のおすすめポイント

  • 堀江さん:ツールの使い方とかでなく、CI/CDとは、というところから書いた
  • 菊池さん:公式にはまだJUnit 4なのに、JUnit 5を動かせるのが楽しい。個人的にそうゆうのが好きなので紹介した。Parameterized Testは便利で使える。この分量が大きくなってしまって章立てを変えた
  • 平田さん:Appiumまわりは、本書のために会社でUIテストやりたい人を募って実際に導入した成果を書いている。さらっと書いてるところも実際は大変だったりした
  • 外山さん:UIテスト導入まわりでは、『システムテスト自動化 標準ガイド』(通称「ギア本」)から、最低限押さえておいてほしい点のピックアップもしている。Espressoに関しては、ドキュメントからだけではわからないところもソースを読んだり試したりした結果を書いてある

システムテスト自動化 標準ガイド CodeZine BOOKS

システムテスト自動化 標準ガイド CodeZine BOOKS

苦労したところ

  • 菊池さん:本が出たあと、Gradle JUnit Pluginの変更がどんどん入ってつらい。ただ、本書の記載内容が使えなくなったわけでなく、便利なアノテーションとかが追加された等。執筆期間にGoogle I/O 2018を挟んだので不安だったが、大きな変更はなく安心した
  • 堀江さん:仕事との兼ね合い、子育てもあるので時間がつらかった
  • 平田さん:執筆中にAppiumのバージョンアップ(1.8 -> 1.9)、uiautomator2 driverのBetaが取れたのはよかった
  • 外山さん:Kotlinを使うかどうか悩んだ。執筆当初はコンパイルが通らないところがあり、Javaで書いた。電書版直前くらいに試したらKotlinもコンパイルが通るようになっていた
  • 日高さん:読むターゲットの選定。初心者なのかバリバリやってる方か。テストのことをちゃんと伝えたい、わかりやすく書きたい。改訂版の予定はまだないが、売上がよかったらぜひやりたい

PEAKSについて

  • PEAKSで書いた書籍を技術書典で売るときにTシャツを作ってもらえた
  • 表紙はなぜこうなったのか?
    • 永野さん@PEAKS:わからない
  • 永野さん@PEAKS:本書は、他の本に比べてクロスレビューが活発だった

自分以外のセクションでおすすめ

  • 外山さん:非同期テスト細かく書いてある、CI/CDとかあまり詳しくなかったので勉強になった
  • 平田さん:自身がiOS寄りなので、4・5章が特に、視点が違って面白かった
  • 菊池さん:2年くらい前、AppiumでAndroid 4系をテストしようとして辛かったのが、今はよくなってること。Circle CIのManual Approvalsで手動でワークフローのトリガを設定できること
  • 堀江さん:1章、テストをなぜ書くのかなど
  • 日高さん:企画段階では250ページ、完成400ページ。これでも削ったところもある。技術の変化が早いので古臭くならないようにした。例えばインストール手順のようなWebで得られるところは割愛している。深夜2時に原稿があがって、その時間から相互レビューがはじまるくらい皆書いていた。編集者は、毎回、頭をリフレッシュして読み直すのが仕事

日高さんの編集について

  • 堀江さん:編集前160ページのセクションが60ページくらいに減った
  • 菊池さん:そこまで減らなかったけど、ごっそり入れ替えとかの指示があると、そこからの辻褄合わせとか大変だった。趣味で小説書いたりしてたので、細かい言い回し等には気を使うほうなるので、その辺りの指摘はそのままにしたところも
  • 平田さん:社内でUIテストを導入しつつ書いたので混乱した部分もあったが、羊さんがヒカリエまで来て話したりした。指摘箇所に理由をつけてくれるので納得感がある
  • 外山さん:著者脱稿して80%くらいの完成度と思っていたら、その後が大変だった。でも読みやすくはなってた。抽象的でなく具体的に書くべき、みたいな指摘とか

普段どこに気をつけてテストしているか

  • 平田さん:QAがやってることを自動にできないかと相談されるが、マニュアルテストをそのまま自動化することは運用まで考えるとROIが良くないので、そこから話す
    • UIテストの安定性。CIに乗せると落ちたり
    • どこまで自動化するか
  • 外山さん:課金などのシステムが出すDialog、テストはできるけどGoogle都合で変わるので大変だけど、大事なので押さえたいところ
  • 堀江さん:CI/CDで、自動と手動をひとつのフローに乗せるべきか。Circle CIでは手動テストの完了をトリガにワークフローを進めてリリースりたりできるので活用している
    • ZOZOにもSWET(SoftWare Engineer in Test)のような組織はあってUIテストは書いてるけど、CI/CDに統合はされていない
    • 手動テストの人がちゃんと探索的テストに注力できるようなフローにする
  • 菊池さん:エンジニア自体が少ないので、UIテストには工数をかけられていない。コストとのバランス

テストを書いたコストがペイしたと思った経験

  • 平田さん:自動テストでバグを見つけるのはよくない*1。テストがある安心感と、正しく動いていることが確認できることが良い。安心してリリースできるのが大事。テストが落ちるのは環境的な問題が多い

現場で実現するために大事なこと、チームプレー

  • 外山さん:自動テストは銀の弾丸ではないので、Unit/UIテストの仕切りが大事。QAが「全部自動化してほしい」と言ってくることもあるが、認識合わせが大変
    • 日高さん:そのときのキーワードは工数
    • 外山さん:工数だけではなく、Unitでやるべきだけど構造上できないのでUIでやったり、事情を汲んでいる
  • 堀江さん:CI/CDがないところに途中から導入したとき。困っていないか聞いて回って、SDKバージョンを上げるのを躊躇するみたいな話を聞く。テストをたくさん書くより、効果的なところから導入していくようにしている

ライブラリ等のバージョンを上げていくか

  • 菊池さん:ライブラリ全般、無理にバージョンを上げる必要はないと思っている
  • 外山さん:テスト系ライブラリはわりとカジュアルに上げる

会場からの質問

QAがテストを書くのか

  • 外山さん:そうしたいが、まだできていない。Excelにシナリオを書けばテスト実行できるくらいにしたいけど、それを作るとコストが見合わないのでできていない
  • 堀江さん:会社に受け入れテストを自動化している部隊がいたが、最近まで知らなかったし、経緯もよくわからない。今後連携していく

テストを書くタイミングについて

テストファーストだと仕様変更で書き直しになる。完成してから書くべきなのか?

  • 変わらないところを中心に書くのがいいのでは。永続化まわりとか
  • UIのほうはあとまわしにして、Unit Testはテストファーストで書く

GUIでテストを作れるツールについて

  • 日本に限らず、増えてきてはいる。どのように使うかによっては使えると思うので、徐々に使えるとは思っている。精度次第?
  • Firebase Test LabのRobo testは、だんだんかしこくなってる。単純なアクティビティ遷移でクラッシュみたいなのは検出してくれる

テストピラミッドの各層でしかできない検証について

  • Unit Testから入って、CIを導入してから、UIテストにかかればいいのでは。CIは入れるべき

プロダクションのライブラリやSDKバージョンを上げることについて

ライブラリやSDKのバージョンを上げるという話があったが、そのときに問題を検出できるように考慮したテストの書き方はありますか?

  • 特にその目的で考慮していることはない
  • Firebase SDKを上げたときにビルド失敗はあった。レポートを社内に展開したりはした
  • ライブラリのバージョンは、上げてもすぐ元が消えるとかある

テストコードの保守性・可読性

本質的でない部分が多くなったり、そもそも何をテストしたかったのかわからなかったりする。工夫はあるか

  • チームが日本人メインであれば、テストメソッドの名前を日本語にすることは有効
    • Instrumentation testのほうは日本語使えない
  • 前設定のコードが多くなるのであれば、Mockitoとかのライブラリを使って簡潔に書けるようにする
  • テストコードの中を、Setup, Exercise, Verify, Teardownにちゃんと分けて、メソッド抽出したりもする。仕様変更などでSetupがごっそり変わることもあるが、分けられていれば対応も容易になる

註:このあたりの用語は、『xUnit Test Patterns』から。テストダブル(Mock等)のパターンも参考になります。

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

テストのリファクタリングに使う時間はトータル何%?

  • 通化をするくらいで、そう多くはない

(AACの)Repositoryのテストについて

Mockを使うUnit Testでは仕様変更の対応が不安。Repositoryまで統合したテストもするべきか

  • OkHttpのMockWebServerを使った統合テストは有効
  • Swaggerとか使ってモックサーバを立てる

既存プロジェクトに対してテストをどう書くか

  • データ層から進めていく
  • セオリーだと、Integration Testなど外側からテストを書いて保護していくが、これは大変。一部アーキテクチャを組み替えながら進められるのであれば、それがいいと思う

所感

会場で質問をされた方の中に「本書を読んでテストを書き始めた」という方もいました。それだけの力のある本が、いい時期に*2書かれたのではないかと思います。

今回のトークセッションでは、著者および編集者の皆さんの熱量(本書に対するものと、テストに対するものの両方)を感じ取ることができ、また共著の大変さを思い出し、改めてじっくり再読しなければ、という気持ちになりました。

本書が広く読まれて(売れて)、改版や、また他分野のテストに関する書籍の出版につながるといいな、と思います。そして、テストを書いてCI/CDすることが当然という世の中が早く来てほしい。

ともかく、著者・編集者、ほか関係者の皆さん、お疲れさまでした。ありがとうございました。

*1:自動テストはリグレッションテストが中心になるので、新規のバグ発見はほとんど期待できないということを踏まえて

*2:ツール・フレームワークの成熟度合いや、Jetpackまわりなど、個人的にそう感じています

システムテスト自動化カンファレンス2017-2を開催しました #stac2017

ヤフー株式会社さんで開催された、テスト自動化研究会の旗艦イベント「システムテスト自動化カンファレンス2017-2」にスタッフとして参加してきました。

testautomationresearch.connpass.com

通算5回目、年1回の開催ですが、昨年分が15月にずれ込んでしまったため「2017」と銘され、今回が「シン・2017」ということになります。まぎらわしくてすいません。

今回はチュートリアルのTAとしてお手伝いしたため余り講演は聞けなかったのですが、今回からはじめた公募セッションやLTが入ったことで、扱う幅が広がったように思え、有意義なカンファレンスであったように思います。

Magic Pod チュートリアル

チュートリアルはキャンセルも出て想定より少ない人数での開催でしたが、その分TAの目が届きやすくなり*1、ほとんどの方がInstagramアプリを題材にした実践課題*2まで完遂できたようで、正直ほっとしました。

内容は、モバイル向けテスト自動化ツールであるMagic Podの使いかたを紹介するもので、これはappium導入のハードルとなっている「操作対象のUI要素を指定するためのロケータの検出」を自動化し、また、テストケースを(テストコードを書くのでなく)ブラウザ上のマウス操作で作成・実行できるというツールです。

Magic Podは無料で使い始めることができますので、興味を持たれた方はぜひお試しください。

www.slideshare.net

講演資料

以下、拾えた範囲でスライドを。追って、テスト自動化研究会の"イベント&アーカイブ"のページにレポートが出るはずです。

テスト自動化と機械学習(STAR機械学習分科会紹介)

TODO: 公開されたら貼ります

翻訳者の同僚が語る「初めての自動テスト」

www.slideshare.net

9月に発売された書籍『初めての自動テスト』について、翻訳者の玉川さんが本日来られないとのことで、同僚である太田さんによる講演。

書籍はこちら。

初めての自動テスト ―Webシステムのための自動テスト基礎

初めての自動テスト ―Webシステムのための自動テスト基礎

GebとSpockではじめるシステムテスト自動化

www.slideshare.net

楽天のレジャー・サービスにおける自動化の取り組みとその効果

www.slideshare.net

How we automate E2E tests at Mercari

TODO: 公開されたら貼ります

TypeScript + PhantomJSを利用した効率的なテスト実施

speakerdeck.com

SI-Toolkitでテスト自動化を実現する現場で遭遇した出来事

www.slideshare.net

自動化困難な状況での活動方法

www.slideshare.net

LT

テスト自動化の前の1.5年にやったこと

楽天の荻野さんのLT。タイトルはうろ覚えですすいません。

レガシーなシステムにテスト自動化を導入したときの、スクリプトを書く前に実施した、開発基盤の整備やQAマネージャのレベルアップといった施策の紹介。それらを整える期間は目に見えた進捗は少ないが、「あとはスクリプトを書くだけ」になってから一気に自動化が進んだ、というお話。

IoT基盤を活用したテスト時間の短縮

折田さんのLT。自動テストを実行するためのPCをたくさん積むという話をよく聞くが、PCはテスト対象の動作待ちがメインなのでスペックは低めでよく、むしろ夜間に通電したまま放置できるものが望ましい、そこでRaspberry Piを使う、というお話。

スタッフ反省会で実機(名前がR2-D2とK-2SO!)を見せていただきました。次は動いてるところが見たい!

テストも開発もするモバイルエンジニアのためのXCUITest/Espressoのすすめ

speakerdeck.com

appiumのメリットは語られるけど、実際にはそれほど楽に享受できるわけではなく、それならばiOSはXCUITest、AndroidはEspressoを使うほうが便利、というお話。

ちなみに私は、開発者テストとしてのIntegration Testingであれば完全に同意。システムテストとして、End to Endとして、という話になると、やはりappiumなどでリリース向けのパッケージ(ipa/apk)をテストすべきかな、とは思います。割り切りですが。

フォローアップのエントリはこちら。

woshidan.hatenablog.com

gaugeによるe2eテスト

テスト自動化ツールGaugeの紹介

テストケース構造をモデル化しよう!:テストカタマリー紹介

www.slideshare.net

*1:逆に介入が多すぎたと感じた方がいたら申し訳ない

*2:ログイン・ログアウトだけでも色々な振る舞いがあって複雑なのです

DevFest Tokyo 2017に行ってきたメモ #DevFest17

10/9に開催されたDevFest Tokyo 2017に行ってきたので、雑なメモ。

f:id:nowsprinting:20171009204630j:plain
会場で写真撮ってなかったので、途中にいたユニコーンガンダム

Tangoで踊らされたオトコがARCoreと向き合う話

  • Tangoではdepthセンサー必須だったが、ARCoreでは普及機のカメラで実現できるようになった(iOS 11のARKitに追随した形)
  • 3本柱
    • モーショントラッキング
    • 水平面の推測 (Environment understanding)
    • Light estimation
  • 画像解析にによる推定
    • TangoではToF(time of flight)
  • Tango → ARCoreで難しくなったこ
  • アプリの開発は、Android Studio 2.3, Unity, UE4
    • API Level 24以上
    • 描画はAndroidネイティブではOpenGLとかになるので、Unityなどを使うほうが楽
  • 実行環境(端末)に、ARCore process appをインストールする必要がある
  • Devices: Pixel XL, Pixel, Galaxy S8
    • Pixel 2/2XL
    • ほかの機種で動かす試みをしている人はいる
  • UX: ARのソリューションでなく、モバイルのソリューションであることを意識したい
  • JAG ARCore(Tango) Working Group - Google+

developers.google.com

github.com

React Nativeアプリをリリースし続けるために、最初に行う8つの取り組み

www.slideshare.net

  • 開発部分はJSにひとでもできるが、一部、Google Play, Xcode, iTunes Connectなど、ネイティブアプリ開発の知見が必要
  • ネイティブのノウハウが必要なところ:設計〜開発の継ぎ目あたり、リリース〜保守
  • init後の作業
    • src/index.jsを作る。ios_index.jsとandroid_index.jsには、import".src/"だけ書く
      • 0.49でそうなったので、0.48以前の人向け
  • application id(Android) , bundle identifier(iOS)
    • init直後は適当なものが入っているので必ず変更する
  • version
    • Semantic Versioningを採用している
    • プラットフォーム間でバージョン番号をそろえるか?
      • そろえたほうが楽、という運用になった
        • リリースノートの書きやすさ
        • Gitのタグ付け
      • package.jsonのversionを元にコピーしている
      • Google Playの制約。version codeは加算のみを許す
        • major+minor+patchを組み立ててGradleで自動生成する案
          • Google Playにアップロードしなおすために都度patchを上げる必要がある
          • 代替案:major+minor+patch+buildという構成(2.1.3-build4 → "2010304"とか)
  • build types
    • デバッグビルド(同じapplication id)を同じ端末にインストールしたい
    • アイコン、表示名も分けないと見分けがつかないので、適切に設定する(スライド参照)
  • 運用に便利なツール
    • Fabric/Crashlytics (JSのエラーは見えない)
    • Fabric/Beta
      • AS plugin/Mac appからリリースできる
      • Google Play/ iTunes Connectでもベータ配布はできるが、タイムラグがあるのとバージョンを上げる必要があるため
      • Deploy Gateでもいい
    • faselane
      • gitにtagをつけてpush → CIサーバがfastlaneでリリースタスクを実行
    • Firebase
      • アナリティクス、ストレージ、ABテスト、プッシュ通知
      • アナリティクスのためだけに使ってる
  • JSのクラッシュレポート
    • Sentryを使う

iOS版でアイコン切り替えができていない、というお話でしたが、デバッグビルド向けのビルドターゲット作り、そこでリリース版とは別のinfo.plistを指定、その中の記述を分けることができます。『iOSアプリテスト自動化入門』のChapter 6「ビルドと配布の自動化」に書きました。

iOSアプリテスト自動化入門

iOSアプリテスト自動化入門

Goによるプロダクト開発 〜設計、テスト、Go2に向けて〜

  • GAE/Goのaetestが遅い件
    • Travis CIからCircle CIに移行して少し早くなった
  • package構成
  • 実装の歴史的経緯を伝えるためにもペアプロは便利
  • 鵜飼さんのスライドを読む
  • 正規表現使いすぎない、map使いすぎない(LLの習慣でやりがち)
  • aetestが遅いので、テストを増やすと遅くなるので余り書けていない
  • メルカリUSはカバレジ80%くらい
  • AWAも80%くらい
  • テストを書いていくといい設計になる
  • Go2

FlutterでAndroid/iOS両対応のアプリ開発

speakerdeck.com

github.com

実践 Appium(書評らしきもの)

11/26に発売となる書籍『実践 Appium』をご恵贈いただき、一足先に拝読させていただきました。

実践 Appium

実践 Appium

『実践 Appium』は、洋書『Appium Essentials』(Packt Publishing, April 2015)の翻訳書です。Appiumのバージョンは原著執筆当時の1.5を前提に書かれており、サンプルコードも原著のものをそのまま使いますが、監訳者によって最新のAppium 1.6での動作も確認されているそうです。

なお、Appiumとは、iOS/Android向けの自動化ツールで、ネイティブアプリ、ハイブリッドアプリ、Webアプリ(Webブラウザ)向けの自動テストスクリプトPythonRubyといった任意の言語で記述・実行できるのが特徴です。 スクリプトは、Webアプリケーションのテスト自動化ツールの定番と言えるSeleniumと同じシンタックスで記述できます。

書かれていること

  • Appiumだけでなく、iOSアプリ、Androidアプリの自動テストを実行するための環境設定(SDKのインストール等)から丁寧に書かれています。開発者だけでなく、QA担当者が読むことを意識されている印象
  • Appiumサーバの設定について、各項目の解説が書かれている
  • iOS/Androidそれぞれの、ネイティブアプリ、ハイブリッドアプリ、Webアプリについて操作方法が書かれている
  • iOSシミュレータ/Androidエミュレータだけでなく、iOS/Android実機でのテスト実行方法も書かれている(iOSのプロビジョニングプロファイルまわりの記述も)
  • GUIの操作について、単純なタップだけでなく、スクロール、スワイプ、スクリーンショット、システムダイアログへの対応など、実際のテストを書くにあたって必要な操作が書かれている

書かれていないこと

基本的に、GUIベースでAppiumサーバを立ち上げ、テストスクリプトを実行する、という範囲のみ書かれています。これらをCLIで実行し、CIに組み込むあたりのノウハウは得られません。

また、日本語版の書き下ろしは無く、サンプルコードも原著のものをPACKTのサーバやGitHubからダウンロードして使います。すでに原著を読まれている方は書い直す必要はなさそうです。

本書をおすすめするポイント

Appiumを使い始める方、触ったことはあるが業務に本格的に導入しようとしている方には特におすすめできます。

Appiumに限らずオープンソースのツールは変化が早く、逆に言えば本書のような書籍の内容は陳腐化が早いと言えます。しかし、いざ着手しようとしたときに断片的な情報をネットで収集するのは骨が折れるものです。 すぐにはAppiumを使用しない、という方も、本書発売を機にAppiumの"現状"を知っておく価値はあるはずです。

関連書籍

Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)

Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)

Seleniumデザインパターン & ベストプラクティス

Seleniumデザインパターン & ベストプラクティス

関連してそうでしていないもの

かえる本(Jenkinsのほう)

Jenkins

Jenkins

かえりマン