Search Unity

こんにちは!わたしの名前はヤンと言います。UnityではToolsmith(Unity内部の開発者の仕事を助けるツール類を開発する役割)を2年ほど担当しています。Unityは近年非常に大きくなったため、それに従って我々の作成したテストも、不安定なテスト、処理に時間がかかるテスト、失敗したものの内部で再現不能なテストの数というのも増加の一途を辿っていました。このブログ記事はそれらのテストについて私たちがどのように対処しているのかについてお話しするものです。…が、その前に私たちがまずどのようにして自動化環境を構築しているのかについてお話ししましょう。その方が、私たちのチャレンジがどういうものか分かりやすくなるかと思います。

Unityでは、私たちは沢山の異なるテストフレームワーク(Figure 1 参照)と、テストスイートを使っています:

  • ランタイムテスト(Runtime Tests)はUnityの公開されランタイム用APIを全てのプラットフォームで検証するテストです。
  • 結合テスト(Integration Tests)はランタイムテストで検証するのが難しい要項についてテストを行うものです – 結合テストはUnityエディターの機能やキャッシュサーバー、バグレポーターなどを含んだ検証を行うことが出来ます。
  • ネイティブC++テスト(Native C++ Tests) は、ネイティブコード層の機能をスクリプトレイヤーを介すことなく直接検証するテストです。
  • グラフィックテスト(Graphics Tests)は描画に関するテストで、比較対象となる(あらかじめ用意された)画像データとテストコードによるレンダリング結果を比較して、正しい描画結果になっているかを検証します。
  • ほかにも、パフォーマンステスト(Performance Tests)、ロード処理テスト(Load Tests)、IMGUI(OnGUI)のテストなど、沢山のテストスイートがあります。
Figure 1. Testing frameworks at Unity

Figure 1. Unityのテストフレームワーク

全体的な構造についてザックリと説明すると、全てのテストはそのテストが使用するフレームワーク毎に異なるサブセットとしてグループ化されています。しかしながら、これらのテストはさらにプラットフォーム、実行頻度、実行時間や他のいくつかの基準によってさらに分類されます。

これほど多くのテストフレームワークやテストランナーを管理するのは簡単ではありません。ですので、1年ほど前から統合テストランナー(Unified Test Runner, UTR)というものを開発しました。統合テストランナーは全てのテストを実行する統一的なエントリポイントとして機能します。UTRはどのフレームワークのテストを実行する時でも玄関口(facade) となります。(Figure 2参照)UTRを開発したことで、だれでも、どのテストでもコマンドラインから一様に実行できる環境が実現しました。

Figure 2. Unified Test Runner Facade

Figure 2. Unified Test Runner ファサード

すべてのテスト実行結果(artifacts)はフレームワークによらず同じ場所にコピーされて集められ、統一的なルールでグループ化・整頓されます。UTRはさらに:

  •  -testfilter=TestName とオプションをつけることで、実行するテストを横断的にフィルター出来ます。
  • テストの実行経過を全てのテストスイートについて同じ形で取得できます。

UTRははじめ、開発者のローカル環境で主に利用されていました。しかしながら私たちは統合テストランナーをビルドファームでも使われてほしいと考えていたので、その後ビルドファーム用に利用できるための改善を始めました。ここでのポイントは、テストがローカル環境で実行されるのと同じようにビルドファームでも実行されることでした。これは別の言い方をすると、仮に何かがビルドファーム上で失敗したとき、ローカル環境でこれを簡単に再現できるようにする、ということです。そういう風にしたかったのです。

時を経るにつれ、UTRは確実にUnity社内でテストを実行する唯一のエントリポイントになっていきました。この変化がUTRに、テストの実行に続くもう一つの重要なタスクを与えました – ローカル・ビルドファームを問わない、テスト実行結果とデータの収集です。UTRはテストの実行が終わると、テスト結果とデータをWebサービスにレポートします。これが、テストデータ分析ツール「Hoarder」が産まれた瞬間でした。Hoarderはテスト実行結果のデータを収集・蓄積し、これらのデータへのアクセスを提供します。開発者はHoarderを通して、テスト結果を集約した統計情報や、個別のテスト実行結果まで掘り下げた情報を取得することができます。(Figure 3参照)

Figure 3. Build agents and humans submit data to Hoarder Web Service. Analytics application fetching it

Figure 3. ビルドエージェントと開発者がHoarder Web Serviceがデータを送信し、分析アプリケーションが取得している

このデータからは、私たちは沢山の貴重な発見をした他、時に適切な情報に基づく決断をすることが出来ました。これについては次のブログでさらに深掘りしてお話ししたいと思います。

15 コメント

コメントの配信登録

コメント受付を終了しました。

  1. Dear community,
    I have a question. So, i can’t find information about this issue :
    need automation tests for web enterprise application(unity player in web browser), when part of the data is loaded during rendering scenes (after play button). is it possible in Unity write and run tests at runtime?

  2. jouer

    1. contract wars automated tests too much.

  3. Being in software dev industry for +20 years in customer/providers environments, I think one of the problem with QA resides in the fact that you don’t control runtime environment. This means that you can put lot of effort on patterns, good practices and quality controls, but that will cover just 50% of the potential issue surface (related mostly to dev/human errors along dev processes).

    So yes, all of that stuff is incredibly good and should be done and continued. But in order to significantly reduce your bug report count (which is what matters to customers), you should think of:

    – How to extend your quality processes/controls/monitors/detectors to the end-user environment (ie. my development machine as an Unity dev).
    – Even further, how to extend your quality processes/controls/monitors/detectors to our own users environment (ie. my own customers).

    But most important: understand that asset developers (like I) should be considered as part of your development community (being in an outer-layer from our common customers perspectives – gamers and users). What I mean is that as an asset developer I want usage metrics for my assets as you have for Unity in general, I want Unity to alert me when an upgrade breaks my assets functionality for any reason (ok, not daily but as soon as you publish a beta). I can’t handle the testing needed for every beta put out there for all my assets (well, I can, but I prefer to invest my time in providing real value).

    Keep up the good work guys.

  4. When a reported bug is found to be valid, does Unity add an automated test for that bug to prevent regressions?

    1. Yan Drugalya

      10月 7, 2015 6:44 pm

      This is developers decision. Quite often this happens like you’ve described.

      1. nose descarga

  5. Sorry to sound a bit cynical but the latest release just broke input for Mac on standalone. How is that possible with such a great testing environment that a major platform becomes completely broken?

    If only we could downgrade to a previous version, though lightmapping is unusable there when mixing the lightmap between Windows and Mac.

    1. Yan Drugalya

      10月 7, 2015 3:36 pm

      Unfortunately described solution can not prevent us from having gaps in our test coverage. It helps to solve other class of problems. Does issue below describe your problem? If yes – it is fixed in 5.2.2 http://issuetracker.unity3d.com/issues/osx-input-dot-inputstring-does-not-work-on-mac-osx

      1. I do agree with the original poster that I’m surprised that an automated testing suite for a game engine doesn’t have rigorous testing around input handling. It’s an area where bugs have appeared repeatedly (especially on OS X) and it seems like an area that’s well suited to testing.

        1. Step 1. Build automated testing suite.
          Step 2. Create tests.
          Step 3. Users complain that you haven’t created enough tests.
          Step 4. Users complain that they know the internals better than you do.
          Step 5. Bang head on desk.

        2. Thomas Petersen

          10月 7, 2015 7:11 pm

          The problem with input testing is that in order to exercise the code, you have to run through the entire stack, all the way from input device through platform specific code down to the input layers. And many times the problem resides on the outer layers, so you have to somehow initiate the input of the test from a physical device or mimic the physical device on a driver somewhere.

          Full stack integration tests are incredibly expensive to author, maintain and execute. Especially the maintain and execute part is important, because fragile tests are worse than no tests.

          What could be done is to make sure the test coverage on the unittest level is good, but that requires that the architecture of the system is made so it is testable. I know that the devs working on the new Input System are creating it with just that in mind.

        3. @Thomas Petersen : does that mean that input system is not being tested right now and will only be when the new one will be released ?
          QA should play a game built with the release on main platforms as the last integration test :)

      2. Thanks for the reply, i understand software development is a very difficult indeed! Though i’m confident such a large issue will be fixed promptly the fact that it was shipped seems like a pretty gross error and causes us a lot of headache.

    2. I agree, you’d have thought that if you know that you have something that your automated tests don’t cover, that’s as critical as keyboard input, then you might test it manually before releasing? Or at least fix it in one of the subsequent two patch release or point release? Seems like maybe you’re relying on automated tests too much.