この記事はTVer Advent Calendar 2025 1日目の記事です。
どうも、TVerでエンジニアリングマネージャーをしている@ukitakaです！
みんな締め切りにビビっているのか1日目の枠がずっと空いてたので、去年に引き続き今年もアドベントカレンダーのトップバッターをやることにしました。
今回はTVerで今年から本格的に進めているテスト自動化の取り組みにおいて、どんな課題が発生し、どう乗り越えようとしているのかについてお話しします。 まだ成し遂げていないことも多く含まれますが、「こんなことをやっていこうと思っている」という野望の話だと思って読んでいただければ幸いです。
TVerのシステムの特性と自動テストへの壁
TVerのシステムの特徴の一つとして、アプリやWebのフロントエンドから外部のシステム (境界外のシステム) への直接的な依存が多くあるということがあげられます。
システム連携に問題があると、TVerの根幹である動画視聴や広告配信など正しく行えなくなったりと致命的な影響が出てしまうため、これらの検証を重要度が高いものとして位置付けています。
全ての検証がアプリのUI上で直接確認できるようなものであればいいのですが、実際にはログ送信や広告リクエストのパラメータ確認など、直接UI上での確認が困難な検証作業が多く含まれています。
現在はどうしているかというと、なんと QAチームがCharles *1というツールを使ってHTTPリクエストを直接確認して検証しています。
これは大変な作業ですし、どうしたって時間がかかってしまいます。
「(自動)ユニットテストなどでカバーすればいいのでは？」と思われるかもしれませんが、現実はそう簡単ではありません。
システム連携が提供されたSDKの奥深くで行われていたり、複数のシステムが複雑に絡み合っていたりするため、サービスの根幹部分をまるごとスタブ置き換えないとダメみたいなことになってしまい、あまり価値のあるテストにならない可能性も高いです。
これらをなるべくテスタブルにすべくリアーキテクチャを推進していたりはいますが、完全にテスタブルな状態に持っていくまでには数年単位で時間がかかってしまい、期待するタイムラインにはなっていません。 品質を担保しつつスピーディーなデリバリーを実現するためにも、この検証をなるはやで自動化することはTVerにとって必須でした。
外部システムとの連携をどう自動テストするか？
外部システムの連携をテストすると言っても、振る舞いを全て検証するのかと言われるともちろんそんなことはありません。
契約による設計（Design by Contract）の考え方を適用すると、外部システムは 事前条件（precondition）が満たされれば、期待される動作を保証するという前提で考えます。
TVerの文脈でいうと、外部システムとの連携における 事前条件は「HTTPリクエストに必要なパラメータが正しい形式で含まれていること」となり、これがフロントエンド側の責務 (= 検証すべきポイント) と定義しました。
この検証を次の2つのアプローチで自動テスト可能にしようとしています。
E2Eテスト(UIテスト) でのHTTPリクエスト検証
2025年末時点ではWebとiOSでE2Eテスト（UIテスト）を推進しており、WebはPlaywright、iOSはXCUITestでテストコードを記述しています。
本来これらのテストは基本的には画面上の要素に対する検証しかできないのですが、TVerではこれを少し拡張してE2Eテスト内で HTTPのリクエストを検証できる仕組みを導入しています。
iOSを例にあげると、HTTPAssertionというライブラリを自作し、次のようにテストコードをかけるようにしています。
// 特定のサーバー(例: アドサーバー)へのリクエストを待つ let request = waitForRequest( url: "https://my-example-ad-server.com/*", method: "GET", timeout: 5.0 ) // HTTPリクエストに期待するクエリパラメータが含まれているかを確認 HTTPAssertQueryParameter(request, name: "expected_param_name", value: "123")
本来のE2Eテストの用法・作法からは少し外れるかもしれませんが、TVerのシステムの特性を踏まえて、ここにシステム連携の検証の責務を持たせました。
Proxyを使ったログ収集とそれに対する自動検証の仕組み
E2Eテストの取り組みは推進しつつも、TVerはiOS/Android/Web以外にもCTV、PS5、プロジェクターなど、幅広いプラットフォームに対応しています。これらすべてをE2Eテストでカバーしようとすると時間がかかりすぎてしまいます。
また「プラットフォームごとの差分を検知したい」「統計的な異常値がないかみたい」などの要望もあったため、各プラットフォームでのE2Eは推進しつつも どこかにHTTPリクエストのログを収集し、それらに対して検証を可能にする仕組み というのを構想しています。
具体的には 以下のようなことを考えています。
- 外部システムとTVerのフロントエンドの間にProxyを置き、そこでログ収集できるようにする
- 集めたログに対してなんらかの方法 (シンプルなルールベースや、統計・機械学習のなにか) で自動的な検証を可能にする
これがあることでURLさえこのProxyに向けられれば、E2Eテストの導入完了を待たなくてもどのプラットフォームにもサクッと導入可能になると考えています。
(まぁまだ構想段階なんですが・・・)
まとめ
システムの特性を踏まえつつ、テスト自動化の方針について考えていることを紹介しました。
TVerは組織もシステムもサービス規模も大きくなり、すべてを人の手で検証することに限界が来つつあります。さらに品質とスピードをあげていくためには、自動化可能なものを自動化していくのは当然として、この記事で紹介したように自動化可能な領域を増やしていく必要もあります。
もしかしたらここで書いたことはソフトウェアテストの一般的な作法や考え方からは外れている部分もあるかもしれません。。ただ、重要なのは、実情に即した実用的なアプローチを選び、実際のビジネス課題を解決できるかどうかということにあるのかなと個人的には思っています。（理論通りで最高のことができれば一番いいですけど、現実は複雑なので...）
明日はShirotoriさんによる「New Relic MCP を試してみた」です、お楽しみに！
