やらなイカ?

たぶん、iOS/Androidアプリの開発・テスト関係。

PlayModeWindowでGameビューの解像度を指定する

PlayModeWindowは、Unity 2022.2で追加されたクラスです。 従来、UnityエディターのGameビューをスクリプトから操作するにはリフレクションによる非公開APIの使用が必要でした。 Unity 2022.2からは、PlayModeWindowクラスの静的メソッドで操作できます。

PlayModeWindowクラスは、PlayModeViewクラス*1を制御する機能を持ち、GameビューとSimulatorビューを切り替えたり、解像度を変更するAPIが提供されています。

docs.unity3d.com

Gameビューへの切り替え

解像度の指定は、SimulatorビューではなくGameビュー表示である必要があります。 次のように切り替えます。

PlayModeWindow.SetViewType(PlayModeWindow.PlayModeViewTypes.GameView);

引数には、GameViewもしくはSimulatorViewを指定できます。

解像度の指定

解像度はSetCustomRenderingResolutionメソッドで変更できます。 Full HD(1920×1080)に変更する場合、次のように指定します。

PlayModeWindow.SetCustomRenderingResolution(1920, 1080, "Full HD");

テスト実行時の解像度を固定する方法1(ICallbacks)

たとえば、すべてのテストで解像度をFull HD(1920×1080)に固定したければ、ICallbacksを使用して次のように実装します。

public class OpenGameViewAtRunStarted : ICallbacks
{
  [InitializeOnLoadMethod]
  private static void SetupTestCallbacks()
  {
    var api = ScriptableObject.CreateInstance<TestRunnerApi>();
    api.RegisterCallbacks(new OpenGameViewAtRunStarted());
  }

  public void RunStarted(ITestAdaptor testsToRun)
  {
    PlayModeWindow.SetViewType(PlayModeWindow.PlayModeViewTypes.GameView);
    PlayModeWindow.SetCustomRenderingResolution(1920, 1080, "Full HD");
  }

  // snip
}

テスト実行時の解像度を固定する方法2(GameViewResolution属性)

テスト実行時に解像度指定する場合は、Test Helperパッケージに含まれるGameViewResolution属性が便利です*2

この属性はテストアセンブリ・クラス・メソッドいずれかに付けることができ、どこにつけても各テストメソッドの実行前(SetUpの前)に処理されます。

すべてのテストで同じ解像度でよければ、次のようにテストアセンブリに付与します*3

[assembly: GameViewResolution(1920, 1080, "Full HD")]

テストごとに個別に指定したいときには、次のようにテストクラスやメソッドに付与できます。

[TestFixture]
public class MyTestClass
{
  [UnityTest]
  [GameViewResolution(1920, 1080, "Full HD")]
  public IEnumerator MyTestMethod()
  {
    // test
  }
}

Test Helperパッケージは、Unity 2019.4以降で利用できます。 Unity 2022.2未満のときはリフレクションによる非公開APIを使用していますので、自分で実装するときの参考にもなるはずです。

github.com

補足

本記事は、拙著『Unity Test Framework完全攻略ガイド 統合テスト編』の第5章「ビジュアルリグレッションテスト」からの抜粋です。

www.nowsprinting.com

テストの基本から知りたい! という方は、『Unity Test Framework完全攻略ガイド 第2版』からお読みください!

www.nowsprinting.com

*1:GameViewクラスおよび、旧Device SimulatorパッケージのSimulatorWindowクラスの親クラス。Device SimulatorがUnity 2021.1からビルトインされて変更されましたが、概念としては変わらず2つのビューの抽象

*2:この属性は、Unity 2022.2未満ではリフレクションで非公開APIを使用して動作します

*3:Play Modeテストアセンブリが複数あるプロジェクトであれば、アセンブリごとに指定が必要です

バッチモードでUnityを実行するときの制限事項と回避方法

本記事は、拙著『Unity Test Framework完全攻略ガイド 統合テスト編』の付録Bから抜粋したものです。

バッチモードとは

バッチモードとは、Unityエディターをコマンドラインから起動するときに -batchmode オプションを付けることでヘッドレス動作するモードです。 ウィンドウモード*1のUnityエディターは実行中さまざまな、人間が応答しなければならないポップアップウィンドウが表示されますが、バッチモードでは表示されません。そのため、CIでテスト実行するときなどに使用されます。

バッチモードの制限事項

本記事執筆時点で判明している、バッチモード実行時の制限事項は次のとおりです。

  • スクリーンサイズは640×480
  • WaitForEndOfFrame を使用できない*2
  • InputSystem.TestFramework を長時間(数十秒)動作させたとき、途中で操作が止まってしまう
  • UnityEngine.InputSystem.LowLevel.InputEventTrace を使用できない
  • -testPlatform オプションでスタンドアロンプレイヤーを指定したとき、バッチモードでなく常にウィンドウモードで起動する

制限事項の回避方法1

バッチモード実行中であっても、EditorWindow.GetWindow() メソッドでUnityエディターのGameビューを開くことで前述の制限を回避できます。

ヘッドレスとは言ったがウィンドウを表示できないとは言っていない

とのこと。

次のコードは、テスト実行前にGameビューを開く ICallbacks の実装例です。

public class OpenGameViewAtRunStarted : ICallbacks
{
  [InitializeOnLoadMethod]
  private static void SetupTestCallbacks()
  {
    var api = ScriptableObject.CreateInstance<TestRunnerApi>();
    api.RegisterCallbacks(new OpenGameViewAtRunStarted());
  }

  public void RunStarted(ITestAdaptor testsToRun)
  {
    var assembly = Assembly.Load("UnityEditor.dll");
    var viewClass = Application.isBatchMode
        ? "UnityEditor.GameView"
        : "UnityEditor.PlayModeView";
    var gameView = assembly.GetType(viewClass);
    EditorWindow.GetWindow(gameView, false, null, true);
  }

  // snip
}

GameView および親クラスである PlayModeView は可視性が internal のため、リフレクションを使用しています。そのため、今後Unityエディターの内部実装変更によって動作しなくなる恐れがあります。

ただし、グラフィックボード・ビデオカードを搭載していないマシン、もしくは -nographics オプションを指定しているときには、EditorWindow.GetWindow() メソッドは機能しません。 エラーにはなりませんがウィンドウも開きません。

なお、当然ですが本当にGameビューが開きます。開発に使用しているPCで動作させたとき、フォーカスを持っていかれたり、そのままキーボード操作がテストに干渉する恐れがありますのでご注意ください。

制限事項の回避方法2

下記リポジトリで公開しているTest Helperパッケージに含まれる FocusGameView 属性も同様の実装をしています。 したがって、この属性をテストアセンブリ・クラス・メソッドいずれかに付けるだけでバッチモードの制限事項を回避できます。

また、Gameビューの解像度を指定する GameViewResolution 属性も同じ処理を含みますので、こちらでも回避できます。

github.com

まとめ

いかがでしたでしょうか?(構文)

この記事が役にたった! という方は、ぜひ『Unity Test Framework完全攻略ガイド 統合テスト編』をお買い求めください!

www.nowsprinting.com

テストの基本から知りたい! という方は、『Unity Test Framework完全攻略ガイド 第2版』からお読みください!

www.nowsprinting.com

*1:便宜上、通常のGUIで動作するUnityエディターを指します。公式の名称ではありません

*2:https://docs.unity3d.com/Manual/CLIBatchmodeCoroutines.html

Unity Test Framework完全攻略ガイド 統合テスト編

Unityの標準テストフレームワークであるUnity Test Frameworkパッケージによる統合テスト(高結合度テスト)の解説本を技術書典14で頒布しています。

想定読者

UnityでC#スクリプトを書けるレベルのソフトウェアエンジニア(プログラマー)を想定しています。 UnityやC#言語自体の解説はしていません。

またUnity Test Frameworkおよびユニットテストに関しては、前著『Unity Test Framework完全攻略ガイド』の知識を前提としています。

www.nowsprinting.com

目次の紹介

各章の内容は次のとおりです。

第1章 ゲーム開発における統合テスト

統合テストは、ユニットテストに比べ、より結合度が高く、実際のゲームに近い(忠実度が高い)状態でテストできるのが利点です。 取り組みかたや観点を相応に変え、ユニットテストと補完関係を築くコツを紹介しています。

第2章 uGUI 操作の自動化

Unity UI(uGUI)の操作を自動化して、主にアウトゲームをテストする方法を紹介しています。 操作の基本、モンキーテスト、シナリオテスト(ページオブジェクトパターン、Automated QAパッケージによるキャプチャ/プレイバック)。

第3章 Input System による操作の自動化

いわゆるNew Input Systemを導入しているゲーム向けに、キーボード・マウス・ゲームパッドなどの入力操作をシミュレートしてテストする方法を紹介しています。 こちらも、操作の基本、モンキーテスト、シナリオテスト(キャプチャ/プレイバック)。

第4章 Input Manager による操作の自動化

LegacyなInput Manager(UnityEngine.Input)は、そのままではテスト不可能です。 テスト可能にするためのヘルパーパッケージの使いかたを紹介しています。

第5章 ビジュアルリグレッションテスト

Graphics Tests Frameworkパッケージによるビジュアルリグレッションテストの紹介と、安定してスクリーンショットを撮影するために、テスト開始時にGameビューの解像度を指定する方法を紹介しています。

第6章 Unity Test Framewok Tips 統合テスト編

前著『Unity Test Framework完全攻略ガイド』でも紹介済みのAPIで、統合テストに利用できるものをピックアップして紹介しています。

付録A ツール・フレームワークの紹介

Unity社およびサードパーティの、統合テスト・システムテスト向けフレームワークを紹介しています。

付録B バッチモードの制限事項と回避方法

本書で紹介している統合レベルのテストは、CIなどで使うバッチモードでは安定動作しないものがあります。 その回避方法を紹介しています。

サンプルコード

サンプルコードは引き続き下記リポジトリを参照してください。

github.com

表紙について

『Unity Test Framework完全攻略ガイド 第2版』に引き続き、りょふ彦(@ryofu1323)さんにお願いしました。 というかその時点で『統合テスト編』の構想があったので、差分も描いてもらっていました。

蛇足ですが、技術書典の「書名の中央をシュリンクして末端は表示する」仕様ほんと素晴らしい。

オフライン会場は「こ04」

5/21(日)、池袋サンシャインシティでのオフライン会場では「こ04」にいます。 当日、物理本の現物はなく「後から印刷」になります。ご了承ください。

オンラインでの頒布について

技術書典マーケットでの購入はこちらから。電子+物理セットがお得です。

techbookfest.org

[6/12]BOOTHにも公開しました。[6/14]物理本も頒布を開始しました。

ikagoya.booth.pm

JetBrains Rider/ReSharperのNamespace does not correspond to file locationインスペクションをUnityプロジェクトで期待どおり診断させる

JetBrains Rider/ReSharperの提供するコードインスペクションに "Namespace does not correspond to file location" があります。 名前空間ディレクトリ階層と一致していることを検査するものですが、Unityプロジェクトの場合デフォルトでは期待どおりの結果が得られません。

例えば次のようなディレクトリ階層のとき、Foo.csの名前空間Fooに、Bar.csはFoo.Barにしたいはずです。

Assets
└── Foo
   ├── Scripts
   │   ├── Editor
   │   │   └── Foo.Editor.asmdef
   │   └── Runtime
   │       ├── Bar
   │       │   └── Bar.cs
   │       ├── Foo.cs
   │       └── Foo.asmdef
   └── Tests
       ├── Editor
       │   └── Foo.Editor.Tests.asmdef
       └── Runtime
           └── Foo.Tests.asmdef

しかし、デフォルトでは次のように診断されます。

なお、Foo.asmdefのRoot Namespaceプロパティ*1に仮にRootを設定すると、要求される名前空間Root.Foo.Scripts.Runtimeになってしまいます。

回避策(診断の無効化)

回避策として、Namespace does not correspond to file locationインスペクションを無効化する手段もあります。 RiderのPreferencesを開き、Editor | Inspection Settings | Inspection Severityで重大度を下げるか、.editorconfigファイルに次のように設定します。

resharper_check_namespace_highlighting = none

しかしこれでは、本来摘出してほしいケースでも無視されてしまいます。

期待どおり診断させる

期待通りの診断をさせるには、名前空間の組み立てルールをRiderに指示する必要があります。 具体的には、名前空間に含めたくないディレクトScripts, Runtime, Testsを無視するよう設定します*2

Riderで無視させたいフォルダを右クリックしてコンテキストメニューを開き、Properties...をクリックしてFolder Propertiesダイアログを開き、Namespace providerのチェックを外します。

これを無効化したいフォルダすべてに行ないます。 この設定は、プロジェクトのルートディレクトリにアセンブリ名.csproj.DotSettingsというファイル名で保存されますので、忘れずにVCSにコミットします。

UPMパッケージの場合

UPMパッケージの場合、次のようなディレクトリ階層が推奨されています*3

Packages
└── your.package.name
   ├── Editor
   │   └── Foo.Editor.asmdef
   ├── Runtime
   │   └── Foo.asmdef
   └── Tests
       ├── Editor
       │   └── Foo.Editor.Tests.asmdef
       └── Runtime
           └── Foo.Tests.asmdef

診断される名前空間からyour.package.nameは除かれますので、Assets下と同じようにRuntimeTestsを無視するよう設定するだけでは、Runtime下とTests下は名前空間なし、各Editor下はEditorのみとなってしまいます。

そこで、各asmdefのRoot NamespaceFooを設定することで期待どおりの名前空間を得られます。

Create Script Folders and Assemblies with Testsエディタ拡張

Create Script Folders and Assemblies with Testsは、上記のようなRuntime, TestsおよびそれぞれのEditorフォルダを生成、asmdefのAssembly Definition Referencesを適切に設定してくれるエディタ拡張です。

github.com

こちらのv1.2で、本記事にあるNamespace provider設定も行うようにしました。

openupm-cliでインストールできます。

openupm add com.nowsprinting.create-script-folders-with-tests

インストール後、フォルダを作りたいところでコンテキストメニューを開き、Create | C# Script Folders and Assemblies with Testsを選択、フォルダ名を入力すると、フォルダ構成とasmdefそしてDotSettingsファイルが生成されます。

あまり頻繁に使うものでもありませんが、便利ですのでぜひご利用ください。

蛇足

デフォルトで名前空間の解釈をしてほしい、という要望は投げたのですが*4、Unity側のAPIの問題で実現できないそうです…

参考

www.jetbrains.com

www.jetbrains.com

www.jetbrains.com

*1:Unity 2020.2で追加されました

*2:テストの名前空間にTestsを付けるかは好みの問題ですが、私は付けない派

*3:https://docs.unity3d.com/Manual/cus-layout.html

*4:https://youtrack.jetbrains.com/issue/RIDER-87752/Interpretation-of-RootNamespace-is-not-as-expected

UPMパッケージのテストワークフロー事例

自作UPM (Unity Package Manager)パッケージをGitHub Actions上でテストするためのワークフローが確立できたので紹介します。

前提とするのは、リポジトリのルートがパッケージのルートディレクトリである(package.jsonがある)構成です。 Unityプロジェクトの一部をUPMパッケージとして公開している構成でも、パスを書き換えるなどすることで応用できるはずです*1

また、テストアセンブリの名前末尾が .Tests であることを前提としています*2

実現していることは次のとおりです。

  • 先行ジョブのキャンセル
  • 複数Unityバージョンでのテスト実行(互換性)
  • テスト実行用Unityプロジェクトの生成
  • テスト実行のための依存関係の解決
  • テスト実行
  • コードカバレッジの集計
  • Slack通知

以下、処理順に説明します。 記事の最後に、実際に動作しているリポジトリのURLを紹介しています。

ワークフロー解説

前提として、このワークフローは、Pull Requestへのpushおよび、masterブランチへのマージで実行されます。ただしMarkdownファイルおよび test.yml 以外のワークフローの更新ではトリガしないようにしています。

on:
  push:
    branches:
      - master
    paths-ignore:
      - '**.md'
      - '.github/'
      - '!.github/workflows/test.yml'
  pull_request:
    types: [ opened, synchronize, reopened ]  # Same as default
    paths-ignore:
      - '**.md'
      - '.github/'
      - '!.github/workflows/test.yml'

先行ジョブのキャンセル

同一ブランチでワークフロー動作中に新たなpushがあったとき、先行しているジョブをキャンセルするよう設定しています。

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

複数Unityバージョンでの実行設定

matrixにテストを実行するUnityバージョンを設定します。 includeは、コードカバレッジの集計を実行するバージョン1つ(下例ではUnity 2022.2.5f1)にのみoctocovフラグを立てています。

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        unityVersion:
          - 2019.4.40f1
          - 2020.3.42f1
          - 2021.3.15f1
          - 2022.2.5f1
        include:
          - unityVersion: 2022.2.5f1
            octocov: true

以降のステップは、Unityバージョンごとに実行されます。

チェックアウト

サブモジュールがある場合はsubmodulestruerecursiveを指定します。 Git LFSにテスト実行に必要なファイルが存在する場合はlfsも設定します。

      - name: Checkout repository
        uses: actions/checkout@v3
        with:
          submodules: false
          lfs: false

テスト実行用Unityプロジェクトの生成

テスト実行に使用する空のUnityプロジェクトをUnityProject~ディレクトリに生成します*3。 末尾に~をつけることで、Unityの管理対象にならないようにしています。

      - name: Crete project for tests
        uses: nowsprinting/create-unity-project-action@v2
        with:
          project-path: UnityProject~

空プロジェクトの生成には自作のActionを使用しています。Unityライセンス不要*4で、Unity 2018.1.0f1*5プロジェクトを生成するものです。

github.com

テスト実行のための依存関係の解決

最低限、リポジトリ直下のディレクトリをPackages/manifest.jsondependenciesに追加する必要がありますし、UniTaskなどサードパーティのパッケージに依存している場合はScoped Registriesの設定も必要です。

また、Unity Test FrameworkパッケージのアップデートおよびCode Coverageパッケージもインストールしておきます*6

manifest.jsonの更新には、openupm-cliを使用しています。

      - name: Set package name
        run: |
          echo "package_name=$(grep -o -E '"name": "(.+)"' ./package.json | cut -d ' ' -f2)" >> "$GITHUB_ENV"

      - name: Install dependencies
        run: |
          npm install -g openupm-cli
          openupm add -f com.unity.test-framework@1.3.2
          openupm add -f com.unity.testtools.codecoverage@1.2.2
          openupm add -f com.cysharp.unitask@2.3.3
          openupm add -ft "${{ env.package_name }}"@file:../../
        working-directory: ${{ env.CREATED_PROJECT_PATH }}

openupm add-fオプションは、インストールするパッケージのバージョン制限を無視してくれます。 この時点でUnityプロジェクトは2018なので、前提条件を満たさないパッケージもあるためです。 実際に使用するUnityバージョンはテスト実行時に指定し、そこでアップデートが走ります。

また-tオプションは、manifest.jsontestablesに追加し、パッケージをテスト実行対象にしてくれるものです。

[2024/04/29追記] CIで使用しているLinux editorにはいくつかバグがあり、対象パッケージをローカルパッケージとしてインストールする方式では問題が出ることがありました*7*8。 現在は、直接Packages下にチェックアウトして埋め込みパッケージ(embedded package)扱いにすることで問題を回避できています。

テスト実行

テスト実行前に、Code Coverageパッケージのフィルタを組み立てます。 フィルタを適切に設定しないと開発対象外のコードまで含まれてしまいテスト実行に時間がかかりますし、カバレッジの数値にも影響します。 またテストコードは常にカバレッジ100%になるため、これも除くべきです。

次のように、リポジトリに含まれるasmdefファイルすべて(末尾.Testsは除く)と、Assets下を対象にしています*9

      - name: Set coverage assembly filters
        run: |
          assemblies=$(find . -name "*.asmdef" -maxdepth 3 | sed -e s/.*\\//\+/ | sed -e s/\\.asmdef// | sed -e s/^.*\\.Tests//)
          echo "assembly_filters=$(echo ${assemblies[*]} | sed -e s/\ /,/g),+<assets>,-*.Tests" >> "$GITHUB_ENV"

テスト実行にはgame-ci/unity-test-runnerを使用しています。ポイントは、

  • unityVersionにmatrixのUnityバージョンを指定
  • projectPathに生成したUnityプロジェクトのパスを設定
  • customParametersにはGitHub Actiuons上で実行したくないテストをスキップする指定

coverageOptionsの設定内容については Using Code Coverage in batchmode | Code Coverage | 1.2.5 を参照してください。

      - name: Run tests
        uses: game-ci/unity-test-runner@v2
        with:
          githubToken: ${{ secrets.GITHUB_TOKEN }}
          unityVersion: ${{ matrix.unityVersion }}
          checkName: test result (${{ matrix.unityVersion }})
          projectPath: ${{ env.CREATED_PROJECT_PATH }}
          customParameters: -testCategory "!IgnoreCI"
          coverageOptions: generateAdditionalMetrics;generateTestReferences;generateHtmlReport;generateAdditionalReports;dontClear;assemblyFilters:${{ env.assembly_filters }}
          UNITY_LICENSE: ${{ secrets[env.secret_key] }}
        id: test

コードカバレッジの集計

Code Coverageパッケージv1.2からカバレッジ情報をLCOV形式でも出力してくれるようになったため、octocovによる集計が可能になりました。 カバレッジやcode:test比の増減をPull Requestコメントやジョブサマリに貼ってくれたりするので便利です。

事前に.octocovファイルにあるカバレッジレポートのパスをgame-ci/unity-test-runnerの出力パスに書き換えてから実行しています。

      - name: Set coverage path for octocov
        run: sed -i -r 's/\.\/Logs/${{ steps.test.outputs.coveragePath }}/' .octocov.yml
        if: ${{ matrix.octocov }}

      - name: Run octocov
        uses: k1LoW/octocov-action@v0
        if: ${{ matrix.octocov }}

このステップはレポートの重複を避けるため、matrixに設定したoctocovフラグの付けられたバージョンでのみ実行しています。

Slack通知

matrixで実行した全テストの終了を待ち合わせてSlackで通知しています。 待ち合わせはneedsで、またテスト失敗も拾うためにif: always()を追加しています。

通知にはGamesight/slack-workflow-statusを使用しています*10

  notify:
    needs: test
    runs-on: ubuntu-latest
    if: always()

    steps:
      - uses: Gamesight/slack-workflow-status@v1.2.0
        with:
          repo_token: ${{ secrets.GITHUB_TOKEN }}
          slack_webhook_url: ${{ secrets.SLACK_WEBHOOK_URL }}

このワークフローが完走したときのジョブは次のようになります。

リポジトリ紹介

紹介したワークフローは、次のリポジトリで実際に使用しています*11。ワークフローはどれもほぼ同じものを使い回せています(依存パッケージの違い程度)。

blender-like-sceneview-hotkeys

Blender 的なテンキー操作でSceneViewの視点を操作できるエディタ拡張

github.com

紹介記事

www.nowsprinting.com

create-script-folders-with-tests

C#スクリプトを置くRuntimeとEditor、およびそれぞれのTestsフォルダとasmdefを生成してreferencesの設定まで行なうエディタ拡張*12

github.com

test-helper.monkey

uGUIを対象としたモンキーテストのリファレンス実装とヘルパーライブラリ(いまのところ)

github.com

紹介したAction・ツールまとめ

github.com

github.com

github.com

github.com

github.com

宣伝

テストの書きかたについてはこちらを参照

www.nowsprinting.com

*1:作業用Unityプロジェクトをセットでリポジトリに入れていればそのままテスト実行できるのですが、互換性テストではUnityバージョンをダウングレードできないため、プロジェクトのUnityバージョンを上げずにキープするか、作業用とは別にテスト実行時用のUnityプロジェクトを用意する必要があります。後者の場合、この記事が応用できるはずです

*2:正確にはasmdefファイル名で判断しています。本来であればファイルの中身を見るべきなのですが一致している前提でサボっています

*3:都度生成するので、リポジトリに含まないよう.gitignoreに追加してあります

*4:プロジェクトのテンプレートをコピーしているだけなので

*5:UPMサポートが入ったバージョン

*6:例では依存パッケージのバージョンを指定していますが、省略して常に最新バージョンを使用することもできます

*7:https://github.com/nowsprinting/create-script-folders-with-tests/issues/17

*8:https://github.com/nowsprinting/test-helper/pull/71

*9:通常Assetsは空ですが、Samplesに含まれるテストを実行するためにコピーするケースを想定しています

*10:game-ci/unity-test-runnerと若干相性が悪く、skipされるテストがあると失敗扱いで通知されてしまいます。落ち着いたらどちらかを改善できればと思いつつ…

*11:Unity 2020と2021は実行を省略しています

*12:Unity 2020以降のLinux editorでテストが失敗していますが利用はできます。Unityにバグレポ済み

Unity Test Frameworkの非同期テストで できること/ できないこと

Unity公式のユニットテストレームワークであるUnity Test Frameworkパッケージのバージョン1.3では、非同期テスト(以下Asyncテスト)がサポートされました。

改めて、できること/ できないことを確認してまとめました。

できること

非同期(async)メソッドの呼び出し

Test属性のテストにasyncキーワードを付与することで、テストメソッド内でasyncメソッドを呼び、その完了を待つことができます。

また、SetUpおよびTearDown属性も非同期メソッドに付与できます。 ただしUnitySetUp属性とは異なり、SetUp属性によるセットアップメソッドはドメインリロード*1の後に再実行されません。

サンプルコードなどは次の記事を参照してください。

www.nowsprinting.com

パラメタライズドテスト

次の属性はUnityTest属性と組み合わせて使用できませんでしたが、Asyncテストでは使用できます。

  • TestCase属性
  • TestCaseSource属性
  • Pairwise属性
  • Sequential属性

これら属性の使いかたについては『Unity Test Framework完全攻略ガイド』の第8章「パラメタライズドテスト」を参照してください。

www.nowsprinting.com

できないこと

以下は、Unity Test Framework v1.3.2時点での制限事項です。いずれもバグレポート済みで、修正されたら本記事にも反映する予定です。

[2/24追記] Issue Trackerに登録されています(UUM-25085)。 すでにお困りの方も、今はそうでないが将来お困りになる方も、ぜひvoteをお願いします!

併用するとテストが終了しない属性

次の属性を付けたAsyncテストメソッドは終了しなくなります。

  • MaxTime属性
  • Repeat属性
  • Retry属性

Throws制約による例外の検証

次のようにThrows制約を使用した例外の検証にasyncメソッドを指定すると、テストが終了しなくなります。

[Test]
public async Task 非同期メソッドの例外捕捉に制約モデルは使用できない()
{
    Assert.That(
        async () => await ThrowNewExceptionInMethod(),
        Throws.TypeOf<ArgumentException>()
        .And.Message.EqualTo("message!"));
}

クラシックモデルAPIThrowsAsyncも同様です。[11/18訂正]

[Test]
public async Task 非同期メソッドの例外捕捉をThrowsAsyncで行なう例()
{
    Assert.ThrowsAsync<ArgumentException>(
        async () => await ThrowNewExceptionInMethod());
}

今のところ、try-catchで書くしかありません。

[Test]
public async Task 非同期メソッドの例外捕捉をTryCatchで行なう例()
{
    try
    {
        await ThrowNewExceptionInMethod();
        Assert.Fail("例外が出ることを期待しているのでテスト失敗とする");
    }
    catch (ArgumentException expectedException)
    {
        Assert.That(expectedException.Message, Is.EqualTo("message!"));
    }
}

タイムアウトが機能しない

デフォルトではテストは3分でタイムアウトし失敗扱いとなりますが、Asyncテストではこれが機能しません。 Timeout属性で時間を指定しても同様です。

タイムアウトの問題はUnity Test Framework v1.3.4で修正されました

WebGLプレイヤーでTask.Delayが終了しない

Play ModeテストをWebGLプレイヤーで実行するとき、await Task.Delay()を引数1以上で呼び出しているとそのテストは終了しなくなります。 async SetUp/TearDownでも同様です。

await UniTask.Delay()は動作しますので、本事象はUniTaskを使用することで回避できます。

Edit ModeテストではTask.Delayが無効

これはそもそもEdit ModeテストがPlayerLoopで動いていないためで、yield returnステートメントにWaitForSecondsなどが指定できないのと同理由と考えられます。

*1:Edit Modeテストでyield return new RecompileScripts()などを実行したときに発生します。詳しくは『Unity Test Framework完全攻略ガイド』の3.3「Edit Modeテスト固有のyield instructions」を参照してください

UnityTestがWebGL Playerで実行できるようになっていた

Unityの標準テストフレームワークであるUnity Test Frameworkパッケージでは、非同期のテストをコルーチン様式で書くことのできる UnityTest 属性が提供されています。

この UnityTest 属性にはいくつか制限事項があり、WebGL Playerで実行できないことは公式ドキュメントにも以前から書かれていました。

具体的な振る舞いは以前記事に書きました。

www.nowsprinting.com

しかしいつの間にか公式ドキュメントから記述が消えており*1、確認してみたところ、(Unity Test Frameworkではなく)Unityエディター側の修正によって解消されていました。

該当するバグチケットはこちらです*2

issuetracker.unity3d.com

Fixed in 2020.3.42f1, 2021.3.8f1, 2022.1.12f1, 2022.2.0b3, 2023.1.0a4 とあり、実際にUnity 2021.3.8f1で動作することが確認できました*3。 また UnitySetUp および UnityTearDown 属性も同様に動作しました。

なお、Unity Test Frameworkはv1.3.2を使用しています。

また、テスト実行結果がUnityエディターのTest Runnerウィンドウに反映されない(プログレスバーが止まったままとなりキャンセルするしかない)問題も解消していました。

なお、拙書『Unity Test Framework完全攻略ガイド 第2版』ですが、昨年末に増刷したときにも本件に気づいておらず、「5.4 UnityTest属性の制限」にはWebGL Playerで動作しないと書いてあります。 今後の改版時に対応予定です。

www.nowsprinting.com

サンプルコードのほうは対応(WebGL Playerでの実行制限を削除)していますが、masterブランチはUnity 2019 LTSを維持しています。 WebGL Playerでの実行は前述のUnityバージョンにアップグレードしてお試しください。

github.com

非同期(async)テストはWebGL Playerで動作しない

蛇足です。 Unity Test Framework v1.3でサポートされた非同期(async)テストは引き続きWebGL Playerで動作しません*4。 当面はこれまでの UnityTest 属性のテスト同様、UnityPlatform 属性でWebGL Playerでの実行を抑止するしかなさそうです。

www.nowsprinting.com

*1:恐らくv1.3もしくはそれ以降のタイミング。消すのではなく情報残してほしいところ…

*2:Known limitationsに書かれていることでもバグレポートしたら対応される(ことがある)、というのは目から鱗

*3:ついでながら、1つ前のUnity 2021.3.7f1では動作しないことも確認しています

*4:ドキュメントにも書かれていない。ほかにも動かないものがあるのでまとめてバグレポートを出す予定です