DeNA Testing Blog

Make Testing Fun, Smart, and Delighting End-Users

iOSDC Japan 2023にてポスターセッションで発表しました!

こんにちは、SWETグループ所属のkariadです。 9/1〜3に開催されたiOSDC Japan 2023にてポスターセッションで発表をしました。 本記事では当日のポスターに掲載していた補足付きのページを共有します。

20230905191903

ポスターセッションについて

ポスターセッションという形式上、アーカイブ等で見ることができないため、内容をこちらにて共有します。 以下が当日掲載されていたポスターの元になったページとなっており、ポスターはこのリンク先の抜粋になります。

iOSアプリのユニットテストにおけるモックの効果的な使い方と使い分けの提案

この発表の着想はSWET内で「単体テストの考え方/使い方」の輪読会から得ました。 輪読会ではメンバーから多くの意見が出てきて、中々ページが進まないほどに議論が活発です。 その中でテストダブルの扱いについて、輪読会で出てきた議論を参考にし、自分の意見をまとめた形で発表しました。 ページ内でも言及はありますが、絶対的な正解はない議論のため、ユニットテストを書く上での一例として参考になれば幸いです。

また、当日はポスター前にて見にきてくださった方とコミュニケーションを取ることができました。 このパターンではテストダブルに置き換える、置き換えない、といった議論やそもそもユニットテストを書いてもらうにはどうしたらよいかといったことを話すことができました。

iOS Test Nightを開催します!

9〜10月頃(詳細時期未定)にiOS Test Nightを開催を予定しています。 もしテストに関連する話題で話したいことがある!という方がいましたらkariadまたはkuniwakまで連絡をお願いいたします。

また、SWETグループではiOSもそれ以外の技術領域でも自動テストなどに興味がある仲間を募集しています。 もし今回の発表等で興味を持っていただけたらご応募お待ちしています。

「Androidアプリのアーキテクチャにそってテストの書き方を学ぼう」というハンズオンを公開しました

こんにちは。SWETのAndroidチームに所属している外山(@sumio_tym)です。 SWET AndroidチームではAndroidのプロダクトに対する自動テストのサポートをしています。

はじめに

Android公式ドキュメント「アプリ アーキテクチャガイド」で推奨されているアーキテクチャの各レイヤごとに、テストの書き方を学ぶハンズオンを「Androidアプリのアーキテクチャにそってテストの書き方を学ぼう」というタイトルで公開しました。公開したハンズオンはDeNA Codelabsよりリンクされています。

また、来週開催されるDroidKaigi 2023のDeNAブースにて、SWET Androidチームのメンバーが本ハンズオンの簡単な解説を行います。 ブースに来て下さった皆さんが選んだトピックについて個別に解説しようと思いますので、興味がある方は是非ブースにお越しください。

ハンズオンの内容

本ハンズオンは、「Now in Android App」アプリを題材に、アプリアーキテクチャのレイヤにそってテストの書き方を学ぶ内容になっています。

Now in Android AppはAndroid開発者が参考にできるように作られた公式のサンプルアプリですが、それをハンズオンの演習内容に合うようにカスタマイズしています。

ハンズオンの目次は次のとおりです。

  • データレイヤをテストする
    • API通信をするコードのテストを実装しながらCoroutineのテストについて学ぶ
    • データソースに応じたテストの書き方を学ぶ
      • データベース(Room)のテストを書く
      • DataStoreのテストを書く
      • オンメモリキャッシュのテストを書く
  • UIレイヤをテストする
    • ViewModelをテストする
    • Jetpack Composeをテストする
      • Composeのユニットテストについて学ぶ
      • ViewModelを結合してComposeをテストする
      • ComposeのNavigationをテストする

なぜハンズオンを作ったのか

Androidアプリ開発で採用される技術要素やアーキテクチャは年々移り変わっています。 DeNAにおいても、Kotlin Coroutines/Flow、Dagger Hilt、Jetpack Composeなどが使われるようになり、 それらのテストの書き方についての質問がSWET Androidチームに寄せられたり、サポートの要望を受けるケースが増えていました。

そこで、現在使われている技術要素へのテストの書き方をDeNAのAndroid開発者が習得できるように、 公式サンプルアプリ「Now in Android App」を題材にしたテストハンズオンを企画しました。

Now in Androidアプリは、公式のアーキテクチャガイドや、テストのドキュメントに忠実にしたがって作られており、Android開発で主流となっている技術要素を採用しています。 そのため、本アプリを題材としたハンズオンを作れば、次のトピックをまとめて学ぶことができると考えました。

  • 推奨アーキテクチャの各レイヤに対応したテストの書き方
  • 各技術要素に対応したテストの書き方

作成したハンズオンは、毎週開催されているAndroidの社内勉強会「Android.Tuesday」の枠を借りてトピックごとに実施しました。 参加者へのアンケートでは、多くの方から「技術的な知見が得られた」という回答をいただいており、当初の目的は達成できたと考えています。 また、当日参加できなかった人のために、実施したときの動画を社内に公開しています。

今回公開したハンズオンは、それを社外に公開できるように体裁を整えたものになっています。 皆さんがテストを書くときの参考にしていただければ幸いです。

DroidKaigi 2023でお会いしましょう

「興味はあるけど読む時間がない」「手っ取り早くポイントを知りたい」という方のために、 DroidKaigi 2023のDeNAブースにて、個別に本ハンズオンの簡単な解説をしたいと思います。 気になるトピックがありましたら、是非DeNAブースにお立ち寄りいただき、SWETメンバーに声を掛けてみてください*1

皆さんとブースでお会いできるのを楽しみにしています!

*1:SWETメンバーが不在のときもあります。そのときは申し訳ありませんが時間を改めてお立ち寄りください

Lint Night #2を開催します!

こんにちは、SWETグループの稲垣( @get_me_power )です。 Lintに関する知識を共有することを目的として、2022/11/18に Lint Night #1を開催しました。

今回、約半年ぶりで復活、Lint Night #2をオフライン・オンライン同時開催します!

Lint Nightはプログラミング言語不問でLintに関するトピックを取り扱う勉強会です。ここでLintとはソースコードや文書を静的に解析して問題をみつけるツールのことです。ただ、どこまでをLintとするかには幅があるようです。(Lintの定義ついては次のスライドをご覧ください)

今回のLint Nightも次の方々をお招きしており、たっぷりとLintに関する知見の共有や議論が行えるイベントとなっております。

  • Emacsの構文チェック拡張機能flycheckの開発者でありPHPStanの有識者である@tadsanさん

https://twitter.com/cloud10designstwitter.com https://twitter.com/tadsantwitter.com https://twitter.com/kitasuketwitter.com

Lintを使ったことがある人、Lintを作ってみたい人、なんでもいいから問題解決の引き出しを増やしたい人、ぜひご参加ください!

オフライン限定になりますが、懇親会も予定しています。 2023/08/04のLint Night #2でみなさんにお会いできるのを楽しみにしています!

CI/CD Test Night #6を開催しました!

こんにちは。SWETのCI/CDチームに所属している井口(@hisa9chi)です。

2023/05/26にCI/CD Test Nightを約3年半ぶりに復活し、第6回目をオフライン/オンラインで開催しました!

本記事では、今回の発表のスライドを紹介していきます。本イベントは当日の登壇を動画でも公開していますのでそちらもあわせてご確認いただければ幸いです。

聴衆の反応

CI/CD Test Night #6 で盛り上がっている様子にtweetをまとめました。

当日の登壇動画

youtu.be

発表スライド紹介

@Kesin11: 「GitHub Actionsオタクによるセルフホストランナーのアーキテクチャ解説」

トップバッターは弊社SWET Grの@Kesin11による「GitHub Actionsオタクによるセルフホストランナーのアーキテクチャ解説」の発表でした。

規模の大きな組織でGitHub Actions Self-hosted runnersを運用する場合で起こりうる課題に関して取り上げ、どのような工夫をして解決しているかを紹介しています。以降に続く登壇者の方々が導入している仕組みも参考にしながら問題解決策の提案をしています。 www.docswell.com

@miyajan: 「philips-labs/terraform-aws-github-runner による GitHub Actions セルフホストランナーの大規模運用」

続いては、サイボウズ株式会社の@miyajan様による「philips-labs/terraform-aws-github-runnerによるGitHub Actionsセルフホストランナーの大規模運用」の発表でした。

GitHub Actions Self-hosted runnersとしてphilips-labs/terraform-aws-github-runnerを活用しており、その選定理由と社内でどのように運用をしているか紹介していただきました。社内の要望から複数のマシンタイプの利用を可能にするためmulti-runnerモジュールも活用されているようです。 www.docswell.com

@s4ichi: 「開発者体験を改善し続けるための Self-hosted runner 運用基盤」

3番目に、クックパッド株式会社の@s4ichi様による「開発者体験を改善し続けるためのSelf-hosted runner運用基盤」の発表でした。

CI環境としてGitHub Actionsを導入しようとした経緯や、導入するために要件からどのような仕組みとしたのかを紹介していただきました。GitHubのWebhookとlambdaやSQSを連携させることにより柔軟なオートスケールを実現されていることや、関連するメトリクスも可視化されているようです。

www.docswell.com

@whywaita: 「バリエーションで差をつける。myshoesの新たな挑戦」

最後に、株式会社サイバーエージェント@whywaita様による「バリエーションで差をつける。myshoesの新たな挑戦」の発表でした。

GitHub Actionsへ移行することとなった経緯を紹介した上で、自社開発のGitHub Actions Self-hosted runnerをオートスケールさせるmyshoesの紹介をしていただきました。発表の中ではSelf-hosted runnerの新たなるバリエーションを増やしたということでmacOSのrunnerも利用可能にしたという点は驚きでした。 speakerdeck.com

懇親会

発表終了後は、オフライン参加者限定で懇親会を開催しました。 参加していただいた皆様それぞれの違う立場で多くのノウハウを共有し会えたことと、時間内では語り尽くせないほど熱く語り尽くした懇親会になっていたと思います。

終わりに

今回登壇していただいた皆様、オフライン/オンラインで参加していただいた皆様のおかげで、無事CI/CD Test Night #6を終えることができました。大変感謝しております。 CI/CD Test Nightは、今後も定期的にイベントを開催する予定ですので、今回参加していただいた方々、参加できなかった方々も次回お会いしましょう!

また、SWETグループではCI/CDに限らずSWETの取り組みに興味があり、私達と一緒に働いてくれる仲間を募集しています。ご応募お待ちしています!

CI/CD Test Nightを復活開催します!

こんにちは、SWETでCI/CDチームの前田( @mad_p )です。

CI/CD関する知識を共有することを目的として、過去数回「CI/CD Test Night」を開催してきました。 今回、約2年半ぶりで復活、CI/CD Test Night #6をハイブリッド開催します!

今回のテーマは「GitHub Actionsセルフホストランナーのインフラ運用」についてです。 去る3月のDeNA Techcon 2023では、Discord上のトークイベント SWET Online のテーマとして「GitHub Actionsのセルフホストランナー」をとりあげました。 当日の議論も大いにもり上がったのですが、話したりない部分も多かったと思います。 今回のCI/CD Test Nightは、このテーマについて、次の方々をお招きして、たっぷりと知見の共有や議論が行えるイベントとなっております。

twitter.com twitter.com twitter.com twitter.com (弊社SWETメンバー)

GitHub Actionsをどのように利用しているかや、セルフホストランナーの構成をどのようにしていてどう運用しているかなどそれぞれの現場での知見が多く知れると思います。 GitHub Actionsを利用している方々はもちろんのこと、セルフホストランナーの構成をどうしようか悩まれている方々、もしくはこれから利用しようとしている方々の参加をお待ちしております。

オフライン限定になりますが、懇親会も予定しています。 5/26のCI/CD Test Night #6でみなさんにお会いできるのを楽しみにしています!

Android Test Night #8を開催しました

こんにちは。SWETのAndroidチームに所属している外山(@sumio_tym)です。

2023/03/10にAndroid Test Night #8を開催しました。 約3年ぶりのオフライン開催で、懇親会も実施しました(同時にオンラインでも配信しました)!

本記事では、今回の発表のスライドを紹介していきます*1

聴衆の反応

Android Test Night #8 で盛り上がっている様子にtweetをまとめました。

発表スライド紹介

@STAR_ZERO「Coroutines Test 入門」

1つめは@STAR_ZEROさんによるKotlin Coroutineが関係するテストの書き方についての発表でした。

suspend関数のテスト、メインスレッドの差し替え方法、Flowのテスト例が簡潔にまとめられており、とても参考になりました。 ついつい忘れてしまいがちなStandardTestDispatcherUnconfinedTestDispatcherの違いや、テストスケジューラの時間制御の方法などが具体例と共に説明されているので、あとから見直すのもよいかもしれません。

@mr_mkeeda「Compose で手に入れた UI の Unit test」

2つめは@mr_mkeedaさんによるCmpose UIのユニットテストについての発表でした。

AndroidにおけるUIのテストは典型的にはInstrumented Testで行いますが、Compose UIのユニットテストであればRobolectricでも安定して動作するとのことでした。 ComposeのテストをRobolectricで動かす場合、RobolectricによってShadow(Robolectricが用意したFake実装)に置き換えられるのはCanvasにとどまるため、テストライブラリへの影響が少ないとの解説が目から鱗でした。

@swiz_ard「KMMのCI/CD」

3つめは@swiz_ardさんによるKMM (Kotlin Multiplatform Mobile)におけるCI/CD構築についての発表でした。

KMMでは、Android・iOSのネイティブコードとKMM共有コードの依存関係を解決する手段として、モノレポ・git submodule・パッケージマネージャーと、それぞれ利害得失が異なる3つの選択肢があるとのことです。 発表では、当初git submoduleが採用されていたプロジェクトを、パッケージマネージャーに移行した事例が紹介されていました。 自分も(KMMではありませんが)git submoduleの扱いには日々苦労させられているため、デメリットが大きくなって移行したという話にはとても共感しました。

懇親会

発表終了後、オフライン参加者で懇親会を開催しました。 参加者同士でたっぷり話せるように2時間確保していたのですが、話題に尽きることなくあっという間に2時間が終わってしまいました!

終わりに

登壇して下さった皆さん、参加して下さった皆さんのお陰で、無事Android Test Night #8を終えることができました。どうもありがとうございました。 Android Test Nightは、今後も定期的にイベントを開催する予定です。 また次回お会いしましょう!

また、SWETグループではAndroidに限らずテストの自動化やCI/CDに興味があり、私達と一緒に働いてくれる仲間を募集しています。ご応募お待ちしています!

*1:録画も公開したかったのですが、Zoomの設定ミスにより録画に失敗していました

Unityプロジェクト向けオートパイロットフレームワークの運用Tips

SWETグループの長谷川( @nowsprinting )です。

開発者自身の手によるUnityプロジェクトの品質向上アプローチのひとつに、ゲームプレイを自動化するオートパイロットによる検証があります。 このアプローチについて、DeNA内で開発・導入を進めているフレームワークAnjinを昨年紹介しました。

swet.dena.com

また、Anjin自体も先日オープンソース化しました。こちらのリポジトリからご利用いただけます。

github.com

本記事では、Anjinの、主にオートパイロットを安定運用するための機能を紹介します。

Automated QAが保存するスクリーンショットの退避

uGUIコンポーネントのシナリオテストを行なう UGUIPlaybackAgent の実装には、 Automated QAパッケージ のRecorded Playback機能を使用しています。 Playback機能は再生操作の前後にスクリーンショットを撮影して Application.persistentDataPath 下に書き出してくれるのですが、新しい操作シナリオの実行がはじまる契機で削除されてしまいます。

Anjinでは複数のシナリオを連続して実行しますので、スクリーンショットを残すのであればすべてのシナリオ分を残したくなります。 そこでAnjinでは、シナリオ実行が終わるたびにAutomated QAの出力先パスを求め*1、退避させる手段を取りました。

詳しくは、UGUIPlaybackAgent クラスの StoreScreenshots メソッドを参照してください。

Unityエディター終了時のクラッシュ対策

Anjinを活用している開発チームでは、Anjinを夜間に定期実行されるように設定しています。 GitHub ActionsワークフローやJenkinsから起動されたAnjinは一定時間動作したらUnityエディターを終了しますが、このとき終了コード0以外で終わってしまうことがあります*2

これを起動元がエラーと判断してアラートを上げてしまうことを回避するため、Anjinは終了時にJUnit Report形式*3のXMLファイルを出力しています。 これにより起動元は、Unityエディターの終了コードではなく、JUnit Reportファイル内の errors の数で合否を判断できます。

JUnit Reportファイル出力の実装は、JUnitReporter クラスを参照してください。

サーバ通信エラーなどによるタイトル戻し対策

「タイトル戻し」とは弊社内での通称ですが、通信エラーなどで進行不能となったときに「タイトル画面に戻ります」といったボタンを表示してタイトル画面からやり直させる振る舞いのことを指します。 もしエラー発生時に動作していたのがモンキーAgentであれば、Agentはそのままタイトル画面に戻るボタンをクリックし、そのままAnjinの実行は継続されます。

しかし、プレイバックAgentなど操作シナリオを再現するAgentでは、本来クリックしたかったボタンの代わりに別のボタンが出現したことでシナリオ継続不可能となってしまい、アラートが上がってしまいます。 エラーの内容が報告すべきものであればこの振る舞いでよいのですが、通信エラーなど無視したいもの(むしろ継続して動作してほしいもの)もあります。 *4

この問題は、次のビルトインAgentを組み合わせることで回避できます。

EmergencyExitAgent

このAgentは、EmergencyExit コンポーネントがアタッチされたボタンの出現を監視し、Scene内に出現したら即時クリックする機能を持っています。 つまり、エラー発生時に表示される「タイトル画面に戻ります」ボタンにこれをアタッチしておけば、プレイバックAgentがシナリオ継続不能と判断する前にタイトルSceneへと遷移できるのです。 Sceneが切り替わった時点でプレイバックAgentは終了してタイトル画面用のAgentに切り替わります。

EmergencyExit は、Anjinが動作している間は常駐して監視を続ける必要があります。それには、AutopilotSettingsにある Observer Agent として登録して使用します *5

OneTimeAgent

たとえばタイトルSceneの操作は、起動後1回目の表示時と2回目以降で異なるシナリオを要求されることがほとんどではないでしょうか。 初回起動では年齢確認やチュートリアルの操作が必要になるためです。

このAgentは1つの子Agentを設定でき、それをオートパイロット実行期間を通じて1回だけ実行します。2回目以降の実行はスキップされます。 これを利用して次のようにAgentを組合わせることで、1回目と2回目以降で異なるシナリオを実行できます。

タイトルScene向け SerialCompositeAgent
    ├── 子1: OneTimeAgent
    │   └── 子: 1回目のシナリオの PlaybackAgent
    └── 子2: 2回目以降シナリオの PlaybackAgent

まとめ

このように、できるだけ単機能・最小限のAgentだけをビルトインAgentとして提供し、Unityエディター上で組み合わせることにより(ノーコードで)ゲームタイトルに合わせたオートパイロット動作を実現できるようにしています。

とはいえ、あまりに複雑な組み合わせを強いるのは本末転倒です。 複雑な要件に対しては、ゲームタイトル固有のカスタムAgent*6をエンジニア(プログラマー)が作成することを検討してください。

We are hiring

SWETグループでは、このようなUnityプロジェクトに対する品質向上アプローチも行っています。 興味を持たれた方は、ぜひ採用情報を確認ください!

*1:パスにはタイムスタンプが含まれるため

*2:プロジェクトによっては高頻度で発生していました

*3:JUnit形式を選択したのは、これを扱えるライブラリがGitHub ActionsやJenkinsプラグインに存在するためです

*4:Anjinはログを監視してエラーを報告しますが、指定した文字列を含むエラーログを無視する設定ができます。前回のブログ記事を参照してください

*5:Observer Agent に設定されたAgentは、DontDestroyOnLoad ではなく、新しいSceneがロードされる度に破棄・生成される点に留意してください

*6:AbstractAgent を継承して実装できます