MimiCatLab
← ホームに戻る

Unity のテスト入門：Test Runner の使い方と仕組みを理解する

Unity Test Framework の基本、EditMode・PlayMode テストの使い分け、NUnit と UnityTest の仕組みを解説します。

Unity のテストとは

Unity には Unity Test Framework が用意されており、ゲームのロジックやエディタ拡張を自動で確認できます。土台は NUnit なので、C# のユニットテストとして書きつつ、Unity 特有のフレーム更新やコルーチンも扱えます。

テストの目的は「正しいことを一度証明する」ことではありません。変更した後も期待どおりに動くことを、短時間で繰り返し確認できる状態を作ることです。

まずは Test Runner を開く

Unity のメニューから Window > General > Test Runner を開きます。ここでテストの作成と実行、成功・失敗の確認を行えます。

テストは通常のスクリプトとは別のテストアセンブリに置きます。Test Runner の「Create a new Test Assembly Folder」を使うと、NUnit を参照する asmdef を含んだフォルダを作成できます。テストを別アセンブリに分けることで、通常のゲームビルドにテスト用コードを含めずに済みます。

EditMode と PlayMode の違い

Unity のテストには二つの実行場所があります。選び方は「Unity の実行状態が必要か」です。

  • EditMode テスト：再生せず、エディタ上で動かします。計算、データ変換、ルール判定、エディタ拡張などに向いており、速く実行できます。
  • PlayMode テスト：再生状態で動かします。MonoBehaviour、GameObject、物理、フレーム更新、シーン遷移など、Unity のランタイムが必要な対象を確認します。

まずは EditMode で書けないかを考えるのがおすすめです。速いテストを多く持ち、必要なところだけ PlayMode にすると、テスト全体の待ち時間を抑えられます。

[Test] で同期的なテストを書く

一つのメソッドをすぐに実行して結果を検証するなら、NUnit の [Test] を使います。例として、HP の下限を 0 に丸める処理をテストしてみます。

using NUnit.Framework;

public class HealthTests
{
    [Test]
    public void Damage_DoesNotMakeHealthNegative()
    {
        var health = new Health(max: 10);

        health.Damage(15);

        Assert.That(health.Current, Is.EqualTo(0));
    }
}

Assert.That の左側に実際の値、右側に期待値を書きます。テスト名は「何をしたとき、どうなるか」が読める名前にすると、失敗一覧を見たときに原因を追いやすくなります。

[UnityTest] が必要になる場面

フレームをまたぐ処理には [UnityTest] を使います。戻り値を IEnumerator にし、yield return null で次のフレームまで待てます。

using System.Collections;
using NUnit.Framework;
using UnityEngine;
using UnityEngine.TestTools;

public class MoverTests
{
    [UnityTest]
    public IEnumerator Mover_MovesOnTheNextFrame()
    {
        var go = new GameObject();
        var mover = go.AddComponent<Mover>();

        mover.MoveRight();

        yield return null;

        Assert.That(go.transform.position.x, Is.GreaterThan(0));
        Object.Destroy(go);
    }
}

これは Unity Test Framework がテストをコルーチンとして進め、フレーム更新の間に制御を戻せるためです。待機、アニメーション、非同期に見えるゲーム処理を確認できます。ただし、時間待ちに頼るテストは不安定になりやすいので、必要最小限に留めます。

何からテストするか

最初から全てをテストする必要はありません。バグが出やすい、仕様が複雑、変更頻度が高い場所から始めると効果的です。

  • スコア・ダメージ・確率などの計算
  • 状態遷移や勝敗判定
  • セーブデータの変換と検証
  • エディタ拡張がアセットを正しく生成するか

逆に、Inspector に設定した値をそのまま表示するだけの処理まで急いでテストする必要はありません。大事なのは、失敗すると困るルールを自動で守れるようにすることです。

まとめ

Unity のテストは、[Test] で速いロジック検証を行い、Unity の実行環境が必要な箇所だけ [UnityTest] と PlayMode を使うのが基本です。Test Runner で小さなテストを一つ実行するところから始めれば、変更への不安を少しずつ減らせます。

Unity Test Framework は EditMode と PlayMode の両方でテストを実行でき、テストアセンブリを基準にテストを検出します。詳しい仕様は Unity の公式ドキュメント も確認してください。

X でシェアする