AndroidSWETグループ、iOS自動テスト領域チームの平田(tarappo)とAndroid自動テスト領域チームの田熊(fgfgtkm)、外山(sumio)でお送りします。Nightは2周年を終えて3年目になりました。Nightに登録されている資料は156件になりました。ここには素晴らしい知見が集まっています。Nightを開催しました。Nightでの登壇について、SWETメンバーが軽くふりかえってみたいと思います。Hotateさんこの発表では、テストコードを書く目的の候補4つを挙げ、そこを出発点にテストを書く範囲を決めていく過程が解説されていました。巷で良く言われている言説をそのまま適用せず、ご自身のプロジェクトの状況と照らし合わせて範囲を絞り込んでいく過程が丁寧に解説されており、とても共感できる内容でした。Hotateさんのプロジェクトにしか当てはまらないとしても、その考え方は他のプロジェクトでも応用できると思います。これからテストを自動化しようと考えている方におすすめの発表でした。Farmを活用したテスト実行をCIと統合する方法ついての紹介でした。テストコードなしでデバイス上で自動テストが実行できるFuzzテスト機能のデモを見せていただきました。Gradleのpluginがあるおかげで導入の敷居は低く、スモークテストをサッとはじめたいときにとてもいいなと思いました。既存プロジェクトへCI/CDをどう導入するか?登壇者:Horie1024さん発表の中では、CI/CDの導入をただ単なる技術の導入ではなく、開発チームの文化を変えるきっかけにしている点が印象的でした。段階的に機能を追加していくうえで、Horie1024さんが実践してきた具体的なプラクティスについても紹介されていました。SWETチームでもテストやCI/CDの導入を行うことがあるのですが、進め方を考える上で大変勉強になる発表でした。11ではいろいろな出来事が起きますが、その中でもXCUItestの挙動について話してくれました。私も出会った事象はありましたが、ここまでいろいろな情報はさすがだなと思います。Xcodeのメジャーアップデート時などにXCUITestにおいて何かしらの問題に出会ったら、Appiumのissueを見に行くのも1つの方法だと思います。登壇者:ikesyoさんSwiftにおけるモック事情について複数のライブラリについて紹介してくれました。本発表では、最近リリースされたMockoloについても触れていました。このライブラリはUber製で、コード生成が高速であることがウリになっています。SWETでも以前調査はしていたのですが、リリースされたばかりの1.1.0については追加調査をしておらず、本発表で改めて試してみないといけないなと思いました。DeNAからの登壇内容DeNAからはMOVのiOSアプリ開発をおこなっているsatoshin21とSWETから平田が登壇しました。Testing登壇者:satoshin21Accessibilityは重要という認識は広まってきてはいますが、優先順位的に下がりがちではあります。Inspectorを使って、常にチェックをするのはなかなか高コストです。そこで、GTXiLibを使ってテストを小さくはじめようという内容です。最近、この手の話を聞く機会も増えており重要性がさらに高まってきたと思っています。私はまだ手を出せていませんが、アクセシビリティについてもテストをしていく必要性を感じています。HirataAppleはここ数年パフォーマンスに関する機能を提供してきています。パフォーマンス改善に関するドキュメントなども提供しています。iOSにおいてはどのように改善サイクルを回すと良いのか、またその時に利用できるもgのとして何があるのかについて登壇をしました。最近、パフォーマンス周りについて力を入れていることもあり今回のような登壇をしました。お話しきれなかったことも多くありましたので、また何かしらの形でアウトプット出来ればと思います。ブログ枠のまとめウホーイさんが作成してくれました。各発表のTwitterでの反応がまとまっており、当日の盛り上がりが伝わってきます。いつもありがとうございます。Nightを合計9回も開催することができました。Nightなどを通してさらなるナレッジを皆様と一緒に世に届けられたらと思います。SWETの仕事に興味を持った方は、SWETメンバーに声をかけていただければと思います。2019の20日目の記事です。SWETグループの長谷川(@nowsprinting)です。MONSTERの及部さん(@TAKAKING22)をファシリテーターにお招きし、SWETでモブプログラミング(以下モブプロ)のワークショップを開催しました。SWETの取り組みの中には、DeNA内の多様なプロダクト開発チームに対してテスト技術を伝える・サポートすることも含まれています。その活動においてモブプロは有効な手段ではないかと考え、より効果的なセッションを運用するためのノウハウを得たいというのが目的です。この記事では、ワークショップを通して感じたことなどをまとめて紹介します。モブプログラミング』をカスタマイズした資料でのイントロダクション、モブセッション、発表会、振り返り、『小さなチーム、大きな仕事を実装するモブプログラミング』+αの講義、という構成でした。+αの部分では、我々SWETが今後モブセッションをファシリテートしていくための知見を話していただけるようリクエストしていましたが、そのアンサーはファシリテートしないカオスを受け入れるの2点でした。言葉だけ見ると突き放すようなインパクトがありますが、実際にワークショップを通して聞くと納得感を得られるものでした。この2点のアンサーを含め、ワークショップ開催にあたって及部さんが整理されたであろう内容がアドベントカレンダー1日目の記事『モブプログラミングを導入するときに考えていること』に書かれていますので、ご興味ある方はあわせて参照をおすすめします。モブセッションモブセッションでは、3〜4人ごとのチーム(モブ)に別れ、それぞれ1台のPCで「自動販売機の機能を実装する」という課題に取り組みました。以下、私のいたモブの話をします。早くホワイトボードから離れ作業に入りました。進めるうち、ストーリーでなく機能に目が行ってしまったり(例えば「品切れ」などの考慮をしはじめたり)、コレクションをどこに持つかのコンセンサスが取れていなくてホワイトボードに戻ったりと迷走し、最初のテストが通ったところで前半セッションを終了。休憩後の後半から、ようやくTDDが回りだしたものの、最後にテストを壊したところでタイムアップ。成果物としては悔いの残る結果に終わりました。initしただけでノーコミット)、実際の業務でモブプロする場合には別の交代契機を検討したほうが良さそうという学びを得ました。個人の感想とまとめこれまでは、モブプロの業務効率についてはあまり意識していませんでした。ワークショップを通じて、通常の分担作業前後のミーティングがモブプロに包括される効果やフロー効率の良さを感じられ、普段からモブプロで業務を進めるという選択も現実的ではないかと思うようになりました。SWETとしては普段から自動テストの効用として、不具合を早期に発見にすることの価値を伝えていますが、モブプロによる細かい軌道修正は同様の効果がありそうです。ほかに印象に残ったのは、同じSWETとはいえ普段同じプロジェクトで仕事をしているわけではないので、お互いのテストの書き方の違いを見られる・教え合えるのは新鮮で楽しい体験でした。Requestレビューでは経緯や細かい点までわざわざ書かないものなので、ペアプロ/モブプロをしないとわからなかったことでしょう。今後の取り組みテストなどのノウハウの共有を目的とするモブプロは、ペアプロに誘うより心理的障壁も低く、セッション中の負荷も軽いため、積極的に使っていこうと試行をはじめています。そのために、(普段のチーム開発ではなく)アドホックに実施するモブプロに最適なテンプレート的なものの整備も進めています。モブプロでは、エンジニア経験が少ない人や他の職種の人であっても、まわりがナビゲートすることでタイピストが務まります。ゲーム開発ではエンジニア以外の様々なロール1と連携して開発を進めていきますが、ところどころでモブプロに参加してもらうことでお互いの考えを知り、暗黙知を共有できるのではないかと考えています。当初想定していた「テスト技術を伝える」ためだけではなく、モブプロそのものの良さを伝え、社内各所で試してもらえるように活動していきたいです。以上のような試みに共感していただけた方、興味を持たれた方、一緒に働いてみようと思ってくれた方。下記職種で採用しておりますので、ぜひご応募ください。(ゲームアーキテクチャ)また、その他の分野へのご応募もお待ちしております。募集職種に関してましては、本ブログサイドバーの「採用情報」の項目をご覧ください。22:58モブプログラミングワークショップを開催した話Tweet2019-12-16SWETの2名が執筆に加わった「iOSテスト全書」が一般発売されましたiOSSWETグループ、iOS自動テスト領域チームの平田(tarappo)です。長いことおまたせしましたが、12/16(月)に「iOSテスト全書」が一般発売されました。私と同じくSWETの細沼(tobi462)が執筆に加わっています。Nightの開始前に写真を撮りました。本書の一般販売を記念して、本エントリーでは本書全体の概要と見どころについて解説します。併せてすでに発売済みの「iOSアプリ開発自動テストの教科書(以後、教科書本)」との想定読者の違いについても説明します。本書の企画は、私が相談をして進めさせてもらいました。昨年(2018年)「Androidテスト全書」の執筆に関わり、周りからの意見もありiOSアプリ開発においても、このようなテストについての本の必要性を強く感じていました。iOSアプリ開発においては、テスト周りにおいて体系的にまとまった情報はあまりありません。一歩踏み込んだ情報となると、日本語でのネット情報は少なくその情報自体最新のものなのかわからないといった状況でもありました。「iOSテスト全書」の企画を立ち上げる前から、私と細沼は「教科書本」の執筆について話が進んでおり執筆がスタートしはじめていました。この本はその名の通り教科書として最初の一歩として道標になると思ってはいたものの、この本だけでは不足している面もあるだろうとも思っていました。そこで、「iOSテスト全書」としてさらに一歩の情報まで載せた本を世に出したいと思い、執筆に加わってほしい人たちに声をかけました。Androidテスト全書が一般発売されたのは2018年11月5日になります。そこから2週間後、11月19日が執筆者と編集者が揃った「iOSテスト全書」のキックオフの日になります。2019年1月28日にクラウドファンディングがスタートし、このたび一般販売となりました。思っていたよりも時間がかかってしまいましたが、良いものができたと思います。手にとっていただければと思います。本書の目次は次のとおりです。1章:テスト自動化入門2章:ユニットテスト(概要)3章:ユニットテスト(XCTest編)4章:ユニットテスト(Quick/Nimble編)5章:BDDによるアプリ開発6章:UIテスト入門7章:XCUITestを使ったUIテスト8章:サードパーティ製ツールとAppium9章:CI/CD自動テストに対する話から、ユニットテスト・UIテスト、そしてそれらを実行するCI/CDについてまで触れています。この中から細沼が2章〜5章(3章共著)、平田が6章と9章を担当しています。「教科書本」はテストに関するものを幅広く扱い、その名前の通り教科書として最初に活用してもらうことを想定しています。「iOSテスト全書」では、より一歩進んだところにもいけるよう自動テストやCI/CDについてもう少しふみこんで書いてあります。このようなiOSアプリ開発におけるテスト周りにフォーカスした本が2019年に2冊も出たということは凄いことだと思っています。ともiOSアプリ開発をおこなっている方は、本書を手にとって頂いて書いてある内容にチャレンジしてみてください。本書の想定読者はPEAKSのページに書いてあるとおり次の方になります。テストについて興味はあるがどうしたらいいかわからない方テストについてもっとよい書き方があるのではないかと悩んでいる方テストにもっと強くなりたい方CI/CDサービスをもっと活用したいと思っている方iOSアプリ開発に携わる人であれば、なにかしら得られるものがある内容になっています。各章の見どころについてはそれぞれの執筆者が書いてくださると思っています。ここでは、我々が執筆した章についての見どころについて次に説明していきたいと思います。私が担当した2章、4章、5章はそれぞれ明確なコンセプトをもって執筆をさせていただきました。ユニットテストにおいて一般的に利用できるテクニックを紹介しています。個人的な見どころは『テストコードの保守性を上げる』のトピックです。テストコードを徐々にリファクタリングしながら保守性を上げる過程がわかるようになっています。3章は共著として一部のみを担当しました。11から追加された『テストプラン』の利用方法について記載しています。個人的にわかりやすく解説できているのではと感じます。4章は『日本語における最強のQuick/Nimbleリソース』をテーマとして執筆しました。知識を体系的に積んで学ぶという点においては、個人的に不足を感じていました。分かりづらい機能についても、できるだけ丁寧な解説を心がけています。Quick/NimbleとBDD(振舞駆動開発)を利用してサンプルアプリを開発する内容になっています。動的なストーリーとして理解を深められる構成になっています。いった意味で、2章〜4章で学んできた内容を締めくくる、ユニットテストにおけるまとめ的な章になっています。6章、9章の見どころ(平田担当)6章の「UIテスト入門」については、UIテストをおこなっていく上で、次のようなフェーズ単位で気にすべきことをまとめました。導入前に検討したほうがいいこと実装中に考慮すべきこと運用時に注意するべきことUIテストは実装して、動いているのを見ると「なんか凄い!」と実装者自身やチームメンバーが感じやすいです。その結果、闇雲にテストコードを追加し、その結果として負債となるコードが生まれることもあります。落ち着いて何をするべきかを考えることが重要です。そこで筆者の経験などを元に、UIテストが実際に現場で活用できるように、それぞれのフェーズで気にすべきことをある程度まとめました。9章の「CI/CD」では、「CI/CDとはなにか」について厚めに述べています。本来は、この話だけで1冊になってしまうぐらいの話ですが、次のようなトピックに注力し説明をしています。CIとはなにか?CDとはなにか?どのようなワークフローを組むかこのような内容は、特定のサービスに限らず他でも汎用的に利用できるものです。実際に利用した形も見ないとイメージが分かりづらいのも事実です。そこで、述べたワークフローの例をもとにiOSアプリ開発で人気のCI/CDサービスであるBitriseを用いて説明をしています。本章の内容により、自社のプロダクトにおいてどのようなワークフローを用意するのが良いかを考える一助になってくれると筆者としては嬉しい限りです。おわりに今回は、一般発売がはじまった「iOSテスト全書」について解説させていただきました。この本が何かしら皆さんにとってプラスとなり、そして今後テストに関する情報がいろいろな媒体を通して世に出てもらえれば筆者としては嬉しい限りです。我々SWETとしては今後「教科書本」や「iOSテスト全書」を社内で活用するよういろいろとおこなっていく予定です。何かしら具体的な活動はそこまで行えておらず、世へのアウトプット出来ていませんが、今後のアウトプットをお待ちいただければと思います。これらの活動に興味がある方はぜひとも次から書かれている内容を元に仲間となっていただけると嬉しい限りです。仲間を募集中SWETチームでは自動テストやCI/CDを活用する仕事に興味を持った方を募集しています。私や他のSWETメンバーに声をかけて頂くかたちでも大丈夫です。2019の2日目の記事です。SWETの加瀬(@Kesin11)です。SWETグループではいくつかの分野ごとにチームを分けて活動をしており、自分は現在CI/CDチームで主にゲーム事業部向けのJenkinsやCI/CDのサポートをしています。Actionsを活用したことについての記事です。xcode-installとはxcode-installはその名の通り、XcodeのインストールやアンインストールをCLIから可能にするxcversionというコマンドを提供するgemです。StoreやAppleのデベロッパー向けサイトからXcodeをダウンロードして手動でインストールしているでしょうから、そのようなツールがなぜ必要なのかと不思議に思われるかもしれません。iOS開発におけるCI/CDには、CircleCIやBitriseといったマネージドサービスを利用することが一般的になってきました。ビルド時間やリポジトリ容量などの問題からそのようなサービスを使いにくいプロダクトも存在します。ビルド用macOSの両方を自前で構築、管理することになります。このビルド用macOSのマシンには、iOSアプリをビルドするための様々なツールを予めセットアップしておく必要があり、Xcodeもその1つです。マシンが1台だけであれば手動で全てのツールをセットアップ可能ですが、ビルドマシン増設を容易にするためSWETではAnsibleを採用してビルドマシンの各種ツールのセットアップを自動化しています。Ansibleでツールをインストールする際には、homebrewのようなCLIツールが提供されていると簡単です。そこで、Xcodeをインストールするにはxcode-installが必要不可欠となります。10.3をインストールしようとしたところ、なぜか失敗するようになっていました。xcode-installが使えなくなるのは自分たちの業務に大変影響があるため、原因を調査して修正することにしました。10系でインストールに失敗するというものでした(issue)。11系のインストールは問題がなかったためか、自分以外にissueで報告している人もいないようでした。10.3のインストールが成功するように修正をしました。xcode-installを修正する難しさ自分は数年前からxcode-installを使用していますが、過去にも度々動作が不安定になったり、特定の人の環境では失敗するという話を社内で聞くことがありました。不安定な要因として、xcode-installに関係する環境の複雑さがありますmacOSのバージョンRubyのバージョンFastlaneのバージョン1インストールしようとしているXcodeのバージョンxcode-installの過去のissueやpull-reqを見てもらうと分かるのですが、自分の環境では動いた/動かなかった、という報告が多いです。11.1の間に含まれる他のバージョンで逆にインストールが失敗してしまうのではないか不安がありました。本来であれば全てのバージョンで動作確認をするべきなのですが、Xcodeのインストールは自分の環境で1回あたり30-40分程度の時間がかかることと、xipをダウンロード後の解凍や検証の処理でCPUパワーが使われるためになかなか辛いものがありました。Actionsを利用したリグレッションテスト手元のmacで実行するのが難しいのであれば、外部のマシンパワーをお借りしたいところです。Actionsがオープンβで個人的にも色々試していた時期で、macOSのVMも使えることが分かっていました。このmacOSのVMを利用してxcode-installの過去のXcodeバージョンのインストール動作確認、すなわちリグレッションテスト(回帰テスト)を行うことを思いつきました。自分が修正パッチを当てる前は、10系のXcodeのインストールが失敗するという状態でしたので、実際に全てのXcodeのバージョンについて問題なくインストールできることを確認することにしました。確認の手順としては以下になります。Actionsを動かし、全てのバージョンで問題なくインストールできることを確認できましたので、自信を持って本家にpull-reqを送ることができました。Actionsは他のCIサービス同様に、publicなリポジトリであればオーナー以外のユーザーも実行ログを確認できます。自分は今回pull-reqを出した側でしたが、レビュワーも実際に動いたログからデグレしていないことを確認できたため、安心できたのではないでしょうか。Actionsのコードはメンテナの方に興味を持ってもらえたようで、別のpull-reqで本家にマージされました🎉xcode-installの動作確認が簡単になることで他の方もコントリビュートしやすくなり、今後は安定性も向上するでしょう。Actionsの少し変わった活用方法をご紹介しました。Actionsでは他のCIサービスと同様にLint、ユニットテスト、デプロイというフローを組み立てるのが一般的だと思いますが、応用次第で今回のように色々と面白いことができるはずです。最後に、CI/CDチームでは社内におけるCI/CD環境の開発・提供を通じて、開発者が開発に専念できるプロセスを支援しています。興味を持たれた方は下記の職種で採用をしておりますので、ぜひご応募ください。Portalにアクセスする処理などにFastlane内部のライブラリが使用されていたりします。Android版に対する「コード改善+テスト導入」の取り組みの紹介Androidこんにちは。SWETの瀬戸(@seto_hi)です。2019年7月下旬からSWETにジョインし、テストが書きにくい設計を改善して自動テストの導入をサポートする取り組みを行っています。Androidアプリの設計の改善を進めてきました。本記事では、2か月間の中で改善した4つの事例について紹介したいと思います。いうタクシーの配車サービスを運営しています。今回リファクタリングを行ったのは、アプリのユーザーが配車依頼から支払いまでを行う、アプリの中心となる画面です。画面の構造は下記のようになっています。常時表示されるActivityと地図Fragmentはシンプルですが、OverlayFragmentの構造がとても複雑な作りとなっています。OverlayFragmentは20種類以上の状態があり、その状態に従って10種類以上のFragmentが差し替わるようになっています。それだけでなく、OverlayFragmentの変更を受けてActivityと地図Fragmentの状態も変更されるので、状態の伝搬や管理が複雑になっています。画面構成の複雑さだけでなく、MOVのユーザーアプリには様々な歴史的経緯があり内部実装は更に複雑になっていました。ActivityとFragmentは見事なFatActivityとFatFragmentとして育っており、修正コストの増加やテストコードの書きづらさといった課題につながっていました。原因を分解し、それぞれについて解決策を考えました。課題1:BaseFragmentと多数のopenメソッドBaseFragmentに空実装のopenメソッドが大量に定義され、各Fragmentはそのメソッドを必要に応じてoverrideしており見通しが悪くなっていました。多くのメソッドはイベントをトリガーとして呼ばれるものだったため、ViewModelにイベント用のLiveDataを用意し、各FragmentでobserveすることによりBaseFragmentへの依存を減らしました。地図の操作イベントはCallback経由で一旦Activityに集約され、再度地図FragmentやOverlayFragmentに分配されていました。Activityに処理を集約する必要は全くなかったので、ViewModelのLiveData経由で地図Fragmentに処理をさせるように変更しました。OverlayFragmentの画面遷移を知らせるイベントもCallback経由で行っていたのですが、NavController.OnDestinationChangedListenerを使い、依存と実装量を減らすことができました。これらの修正によってActivityがFragmentのインスタンスを持つ必要がなくなり、今後不必要な依存を作ってしまう可能性が減りました。課題3:APIコールとCallbacksの実装がActivity/Fragmentにべた書きされているAPIコールとCallbacksの実装がActivity/Fragmentに書かれていたため、Activity/Fragmentの行数が増えるだけでなく、Callback内の処理のテストを書くことが難しくなっていました。従い、設計を変更しました。ViewModelでAPIコールをし、Coroutine化したことでcallbackも少ない行数で実装ができています。architectureに適合するにあたり、今回は3段階のステップを踏みました。Repositoryを作成することでViewModelへの移植をしやすくするCoroutine化でCallback処理の整理をする状態をLiveData化し、ViewModelへ移植する依存を減らしつつ移植することにより、安全な設計変更を行うことができました。改善後のプロダクトコードとテストコードは以下のようになりました。サンプルコードCarRequestRepositoryにはCarRequestを返すgetCarRequest()というメソッドがあります。remoteSource.getCarRequest()}ViewModelではこれを読み込み、LiveDataに保存します。必要であればActivityやFragmentでLiveDataをObserveして値を使うことができます。}}テストこのような設計だとテストも書きやすくなります。CarRequestViewModelのコンストラクタ引数としてCarRequestRespositoryを渡しているため(コンストラクタインジェクション)、モックオブジェクトに差し替えることが容易になります。CarRequestViewModel#loadCarRequest呼んだ際、取得結果をobserverで検知できることを確認するテストは以下のようになります。}}課題4:DialogやDrawerMenuのCallback実装もActivity/Fragmentで行っているこちらも課題3と同様にCallbacksの実装がActivity/Fragmentに書かれていたため、Activity/Fragmentの行数が増えるだけでなく、Callback内の処理のテストを書くことが難しくなっていました。こちらはEnumを利用することで課題を解決しています。サンプルコードまず、メニューの各項目をEnumとして定義します。MOVのアプリではメニューの選択時に新しいActivityを開くようになっているため、Intentの生成メソッドも定義しました。Intent}取り回しを便利にするため、idを元にEnumの要素を取得できるメソッドを定義します。}こういった実装をすることにより、Activity側では以下のように記述するだけで各メニューの選択時の処理ができるようになります。将来的にメニュー項目が増えても、Activity側に修正を入れる必要はありません。}ちなみに、このようにEnumを使った手法はActionMenuやActivityResultにも応用できます。テストenum化することによりテストも書きやすくなります。テストは以下のようになります。}最後に上記のような修正によって、アプリの設計は改善の方向に進み、テストコードも書きやすい状態に変化していきました。このようなアプリの設計改善に限らず、SWETチームでは引き続き自動テストを導入するための取り組みを進めていきます。11でのテスト周りの新機能を紹介します!iOSSWETグループ、iOS自動テスト領域チームの細沼(tobi462)です。11におけるテストまわりの新機能について紹介します!新しく追加された機能は大きく以下の3つです。letに相当する関数なお、メトリクスまわりも大きく進化していますが、本記事では割愛します。関連するWWDC19のセッションを紹介したいと思います。デバッグやメトリクスが解説されているセッションもあわせて紹介します。現在では日本語字幕にも対応しています。見られていない方は是非ご覧ください。Xcode(#413)今回のWWDC19において、自動テストをテーマとした最も大きなセッションです。Bundles」の解説がされます。盛り沢山なセッションとなっています。テストをまだ書いたことがない人にも是非見ていただきたい内容です。11で追加されたデバッグまわりの機能について、解説されたセッションです。上書きしてエミュレートする機能なども紹介されています。iOSアプリ開発者であれば是非とも抑えておきたい機能です。11の新機能について、解説されたセッションです。Plan」や「デバイス状態の上書き」といったデバッグ機能について紹介されています。いったセッションとあわせて見るとより理解が深められる内容かと思います。テスト以外についても多くの機能が追加されています。iOSアプリ開発者であれば必見のセッションといえます。Performance(#417)アプリのメトリクス取得について解説されたセッションです。新しく追加されたMetricKitなどについて解説されています。興味のある方は是非このセッションをご覧ください。11で追加されたテスト周りの新機能について、次の順で解説していきたいと思います。テスト実行における計画(テスト対象、コンフィギュレーション)を管理できる機能となっています。多言語(日本語、英語、など)のテストなどが紹介されていました。したテスト実行の管理をするための仕組みとしては煩雑でした。テスト実行の設定を直感的に分かりやすく管理できるようになりました。Plans(テスト計画)」という名に恥じない機能となっています。既存のスキーム設定から変換する方法が簡単です。Plans...」ボタンから行います。ダイアログが表示されるので、スキーム設定から変換する場合は一番上を選択します。Planに切り替わります。「Tests」と「Configurations」タブから構成される設定画面が表示されます。同様に「実行するテスト対象」を選択する画面となっています。前述した言語設定(日本語、英語など)にくわえカバレッジ取得の有無なども設定可能です。左側のサイドバーにその一覧が表示されるようになっています。Settings」の設定値を継承する仕組みとなっています。複数の設定を用意して実行する例として「日本語」と「英語」の2つのコンフィギュレーションを用意してテスト実行する例を紹介します。左下の「+」ボタンから「Japanese」と「English」というコンフィギュレーションを作成します。Language」の項目を「Japanese」と「English」に設定します。テストナビゲータのコンテキストメニューから実行するコンフィギュレーションを選べるようになります。すべてのコンフィギュレーションでテストを実行してみます。「Japanese」と「English」の2つのコンフィギュレーションで実行されていることが分かります。以下のアイコンからコンフィギュレーションで絞り込むことも出来ます。Plans用のオプションが追加されたので、ここで紹介したいと思います。Plansの一覧を表示するには-showTestPlansオプションが利用できます。Plansを指定する場合は-testPlanを利用します。テストプラン「AllLanguage」を実行なお、-testPlanを指定しないで実行した場合はスキーム設定でデフォルトになっているものが利用されます。次のオプションを利用することで限定することもできます。今まで独立していた以下のようなテスト結果を1つにパッケージするものです。JSONスキーマで仕様が明確化されたJSONでの取得も可能になっています。した変更により、テスト結果リソースの扱いがシンプルに行えるようになりました。それぞれの結果リソースが独立したファイルとして出力されていました。1つの.xcresultファイルとして集約されるようになりました。これまでに比べて「最大で4倍小さいサイズ」のフォーマットとなっているようです。中身の情報を取得できるようになっています。指定したパスに.xcresultファイルを出力することが出来ます。プロジェクトで設定されたDerivedDataフォルダ以下に出力されます。「Xcodeメニュー>File>Open」から.xcresultファイルを選択して開くことが出来ます。すると以下のキャプチャのように、テスト結果をXcode上から閲覧できます。前述したようにxcresulttoolを利用すると、中身のデータを取得することが出来ます。以下は、JSONフォーマットとして情報を取得する例です。json出力されるJSONを抜粋すると以下のようになっています。詳細にデータを取得できるのが分かります。JSONスキーマの取得は以下のコマンドで行えます。get同様に出力結果を抜粋すると以下のようになります。xcresulttoolから確認できます。以前からxccovコマンドによってカバレッジレポートの中身を参照できました。今回から.xcresultファイル形式もサポートされました。.xcresultファイルからカバレッジ確認する際は、以下のコマンドで行えます。ResultBundle.xcresult参考まで出力結果の画面キャプチャを貼っておきます。XCTestに追加されたXCTUnwrap()というAPIについて解説します。アンラップ処理を同時に行うAPIです。これまでは以下のようなコードを書く必要がありました。"Hello")}それがXCTUnwrap()を利用すると以下のように書けるようになります。感じた方もいるかもしれません。「どの箇所で失敗したのか」という情報が失われ原因調査にコストがかかるという欠点があります。今回追加されたXCTUnwrap()を利用していくとよいでしょう。中身を取り出す必要がない場合には以下のように記述できます。Bundle」「XCTUnwrap()」について紹介しました。開発における基盤を支える機能もしっかり進化していたことが分かります。ここ数年でかなり成熟してきたようにも感じます。十分にナレッジを得られていない部分もあると感じています。様々な知見を公開してくださると嬉しい限りです。SWETチームでは自動テストやCI/CDを活用する仕事に興味を持った方を募集しています。私や他のSWETメンバーに声をかけて頂くかたちでも大丈夫です。発表・イベントリポートSWETグループの長谷川(@nowsprinting)です。Runnerを活用して内部品質を向上しよう』と題して、Unityでのゲーム開発におけるユニットテストについての発表を行ないました。Materialsで公開されています。動画も近日中に公開予定です。learning.unity3d.jpセッションについてUniteでテストを扱うセッションは稀で、どのくらい来ていただけるか不安でしたが、400人部屋の8割ほどが埋まっていたように見えました。聴講に来ていただいた方々、ありがとうございました。Unity開発者の皆さんのテストに対する関心の高さを実感でき、今後とも社内外に向けてテストに関する情報発信をしていくモチベーションとさせていただきます。セッション後の質疑応答も、10名ほどの方々と都合30分ほどお話させていただきました。疑問に回答させていただくだけでなく、皆さんそれぞれのテスト観や現場で困っていることなど私のほうでも多くの知見を得ることができ、大変有意義な時間となりました。技術的トピックについての補足および、セッション後の質疑応答の内容については下記個人ブログに書いていますので、ぜひ併せてご覧ください。www.nowsprinting.com"テストを書く文化を根付かせる"試みについてセッションの終盤に「"テストを書く文化を根付かせる"1試み」と題して、DeNA社内のUnityプロジェクトにユニットテストを導入していった経緯をお話しました。SWETグループは、いわゆるQAとは別のアプローチで品質向上を目指す横断的組織であり、各ゲームタイトルの開発チームをサポートする立場です。ユニットテストに関しては、まずは開発チームに現状をヒアリングしつつ「ゲーム開発でテストを書く意味・価値」を考え直すところからスタートし、ようやく一歩目を踏み出せた段階です。私たちの事例は、セッション中にお話したように「タイミングがよかった」に尽きます。続けていくつもりです。以上のような試みに共感していただけた方、興味を持たれた方、一緒に働いてみようと思ってくれた方。下記職種で採用しておりますので、ぜひご応募ください。(ゲームアーキテクチャ)また、その他の分野へのご応募もお待ちしております。募集職種に関してましては、本ブログサイドバーの「採用情報」の項目をご覧ください。2019における@t_wada氏のセッションタイトルの引用です。(1)リンクプライバシーポリシースターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。