『呪術廻戦 ファントムパレード』のバックエンドにおけるテスト実装の取り組み【CAGC2024】

『呪術廻戦 ファントムパレード』のバックエンドチームでは、大規模なソース開発を安定して行うためテスト実装についてルールを策定し取り組んでいます。
本セッションでは、ファンパレのバックエンドにおけるテスト実装の取り組みについてご紹介します。
具体的にどのようなテストを実装しているのか、どのようなことを意識してチーム内で取り組んでいるのかをご説明しつつ、テストを活用した仕組みの例もご紹介させていただきます。

https://cagc.cyberagent.co.jp/2024/session/index.html?id=Mv7FRTUd

©芥見下々／集英社・呪術廻戦製作委員会　©Sumzap, Inc.／TOHO CO., LTD.
Copyright © CyberAgent, Inc.

Transcript

1. 『呪術廻戦 ファントムパレード』の バックエンドにおけるテスト実装の取り組み 1 サーバーサイドエンジニア / 呪術廻戦 ファントムパレード 守田 一喜　Morita Kazuki
2. 『呪術廻戦 ファントムパレード』とは 2
3. 3 『呪術廻戦 ファントムパレードは、 2018年より「週刊少年ジャンプ」 （集英社）にて連載中の 芥見下々（あくたみげげ）氏による 人気漫画を原作としたTVアニメ 『呪術廻戦』を元にした、作品初の スマートフォンゲームです。 TVアニメ『呪術廻戦』の第1期の物語を 追体験できるだけでなく、福岡を舞台にした 『ファンパレ』オリジナルの ストーリーが楽しめる コマンドバトルRPGとなっています。
4. テスト実装について 4
5. バックエンドにおけるテスト実装の役割 5 テストを通して、APIや実装の振る舞いが正しい事を動作確認する レベルアップするリクエスト - キャラのデータ - 消費するアイテムの データ - 何レベル強化するか API レベルアップしたレスポンス - レベルアップした キャラのデータ - 所持数の減った アイテムのデータ テスト用に仮のデータを作って、実行してみる
6. バックエンドにおけるテスト実装の役割 6 テストを通して、APIや実装の振る舞いが正しい事を動作確認する レベルアップするリクエスト - キャラのデータ - 消費するアイテムの データ - 何レベル強化するか API レベルアップしたレスポンス - レベルアップしてない キャラのデータ - 所持数が減ってない アイテムのデータ 想定外の結果となったら、テスト失敗
7. バックエンドにおけるテスト実装の役割 7 テストを通して、APIや実装の振る舞いが正しい事を動作確認する レベルアップメソッドの引数 - キャラのデータ - 何レベル強化するか メ ソ ッ ド レベルアップメソッドの戻り値 - レベルアップした キャラのデータ APIだけでなく、メソッド単位でも実装する
8. これからお話しする事 8 テスト実装の取り組みをご紹介します - テスト実装の取り組み - テスト実装の現状 - テストの活用事例紹介
9. 前提として 9 ファンパレのバックエンドで使用している技術 - 言語: PHP - Webフレームワーク: Laravel - テストフレームワーク: PHPUnit
10. 前提として 10 アーキテクチャはADR+Repositoryパターンを採用
11. テスト実装の取り組み 11
12. テスト実装の取り組み 12 主に3種類のテストを実装しています - Unitテスト - Featureテスト - Integrationテスト 以下の事を重視しています - なるべく全てのメソッドを網羅するテストを書くこと - 不要なDBアクセスを避け、テストを軽くすること
13. Unitテストとは 13 いわゆる単体テストで、 Service系とRepositoryに対してそれぞれ実装
14. Unitテスト実装時のルール 14 「テストが仕様書といっても過言ではない」 - 原則1メソッド1テスト - 異常系のテストも書くこと - Repositoryのテストはデータストアへのアクセスを行う - Serviceのテストはデータストアへのアクセスを行なってはいけない - Mockを利用する
15. Featureテストとは 15 １つのHTTPリクエスト単位の動きをテストする
16. Featureテストの役割 16 主にリクエストのバリデーションが正しいかを検証 レベルアップするリクエスト - キャラAのデータ - 強化アイテム15個 - 「3レベル強化」 チェック項目 • キャラのデータは正しい？ • アイテムの消費数は整数？ • 強化するレベルは正の整数？ テスト用に仮のデータを作って、実行してみる Request
17. Featureテストの役割 17 主にリクエストのバリデーションが正しいかを検証 レベルアップするリクエスト - キャラAのデータ - 強化アイテム15個 - 「-5 レベル強化」 チェック項目 • キャラのデータは正しい？ • アイテムの消費数は整数？ • 強化するレベルは 正の整数ではない 異常なリクエストが、正しくエラーになることを確認 Request
18. Featureテスト実装時のルール 18 - DBの書き込みをしないため、Serviceをmockして扱う - レスポンスは 200 OK かどうかを見る - 実際の返り値はUnitTestで保障されているため 値が正しい事の検証はしない
19. Integrationテストとは 19 結合テストの事 DBにデータを入れてAPI丸ごとの実行をテストする
20. Integrationテスト実装時のルール 20 - Actionごと(APIごと)に必ず書く - mockを使わず、包括的にテストを実施する - 実際にDBにデータを入れてテストする - HTTPステータスではなく、実際のResponseの内容を見て評価する - 正常系のみのテストが好ましい - 1テストごとにデータ挿入、データ削除をしているので truncateする分大変に重い - なるべくテストを軽くするため、ケース数を減らす
21. その他テスト実装に関して 21 その他、以下のようなルールがあります - データプロバイダを使って、入力データのパターンを作ってテストする - factoryを使ってデータを用意する - テストは、マスタの実際のデータを利用する必要はない - なるべくテストを軽く保つこと - 不要なDBアクセスは避ける - テストケースも必要分のみで良い
22. テスト実装の取り組み - まとめ 22 主に3種類のテストを実装しています - Unitテスト - Featureテスト - Integrationテスト 以下の事を重視しています - なるべく全てのメソッドを網羅するテストを書くこと - 不要なDBアクセスを避け、テストを軽くすること
23. テスト実装の現状 23
24. テスト実装の現状 24 ファイル数は以下の通り - Unitテスト 約1150ファイル - Featureテスト 約160ファイル - Integrationテスト 約220ファイル テストケースは7500ケース以上
25. テスト実行にかかる時間 25 テストの実行に掛かる時間は以下の通り - 12分
26. テスト実装にかかる時間 26 話者が3種の実装中でテスト実装に掛かった時間は以下の通り - 規模の大きなAPIの実装 約50分 (実装全体: 約240分) - やや規模の大きなAPI改修 約15分 (改修全体: 約120分) - 小規模な改修 約10分 (改修全体: 約40分) 特に複雑で規模の大きな新規実装においては、 テストの実装はかなり時間がかかってしまう。
27. テストに対するチーム内の意識 27 「テスト実装は、当たり前」の文化が根付いている - サーバーリードエンジニアが強い意思を持っている - テスト実装が欠けているとレビューが通らない チームメンバーが、テスト実装に対して肯定的な考え - チーム発足当初は、手厚いテスト実装に否定的だったメンバーが 現在は肯定的な考えに変わっている例も
28. チームメンバーの思うテストのメリット 28 安心できる/実装を保証できる テストを意識して設計・実装するので、良いコードになりやすい気がする （何をするメソッドか明確な設計・実装になる） 実装中の動作確認がしやすい リファクタがやりやすい 仕様変更によりコードを変更した場合の対応漏れなどに気づける
29. チームメンバーの思うテストのデメリット 29 テスト実装に時間がかかる 書き方に悩むことがある（手が止まる人がたまにいる気がする) どうやってテストすれば良いか分からないケースに時間がかかったりする テストが増えてきて長くなると作業効率が落ちる CIが完了するのを待ったり
30. テストの活用事例 30
31. テストの活用事例について 31 N+1問題の検出する仕組み - Integrationテストを活用 - 実際にDBにデータを挿入、選択するテスト - テスト中のクエリを分析する テストを活用した仕組みを1つご紹介します
32. N+1問題とは 32 データの取得時に、大量のクエリを発行してしまう問題 実装の不備によって引き起こされる 例えばフレンドの情報を取りたい場合 - フレンドの一覧をリストで取得する - フレンドのプロフィールをリストをループして取得する と実装してしまうと、フレンドの人数分クエリを発行してしまう リスト取得で1回、フレンドN人のプロフィール取得にN回 合計N+1回のクエリが発行されるので、N+1問題と呼ばれる
33. N+1問題とは 33 問題の本質は、同じクエリを何度も発行してしまう事 例えばフレンドの情報を取りたい場合 - フレンドの一覧をリストで取得する - フレンドのプロフィールをリストをループして取得する この例では「フレンドのプロフィールを取得する」クエリを 何度も繰り返し実行してしまう 本来は、全てのフレンドのプロフィールを纏めて一度に取得すべき
34. N+1問題の検出 34 Integrationテストをすべて実行していく テストケースごとにDBに吐かれたクエリを集計 LaravelではenableQueryLogを使用すると、 クエリログを有効化できる
35. N+1問題の検出 35 クエリを纏めて、同じクエリの重複を検知 これにより、Prepare文の重複が検出される
36. N+1問題の検出 36 毎週水曜日に、Slackに検出されたテストを通知
37. N+1問題の検出 37 あくまでも、疑わしい箇所の検出 適切な箇所についても検出される場合がある リリース前の、怪しい箇所の洗い出しに役に立った
38. 38 ご清聴ありがとうございました ©芥見下々／集英社・呪術廻戦製作委員会　 ©Sumzap, Inc.／TOHO CO., LTD.