AIゲーム制作ラボ
落とし穴6分で読めます

Unityのテストが「0件」で通る:asmdefの古い書き方が原因だった

list_tests では5件見えているのに、実行すると0件。テスト用 asmdef の書き方が古く、ビルド対象が WebGL のときだけテスト用アセンブリが作られていませんでした。同じ手順で2つのプロジェクトを比べた実測と、直し方です。

Libra

公開 2026年9月16日

この記事の要点5 points

  1. PlayMode テストが1件も実行されないのに、失敗もエラーも出ない。 「合格」と見分けがつかないのが一番危ない。
  2. 原因はテスト用 asmdef が古い書き方(optionalUnityReferences だけ)で、ビルド対象が WebGL のときテスト用アセンブリが作られていなかった
  3. ビルド対象を StandaloneWindows64 に戻したら、同じコードで 5/5 合格した
  4. 同じ WebGL 状態でも、新しい書き方の asmdef を持つプロジェクトは 5/5 実行できた。 asmdef の差だけで再現する。
  5. AI にテストを任せるときは「合格した」ではなく「何件実行されたか」を必ず見る
目次6
検証した環境最終確認 2026年9月16日
  • Unity 6.6(6000.6.0f1)
  • Unity Test Framework 1.8.0
  • Unity CLI 1.0.0-beta.9 の run_tests / list_tests
  • Windows 11

書いてあるのは、この環境で実際に試した結果です。ツールの仕様や料金は変わるので、重要な判断の前には公式の情報も確認してください。

同じ仕様書でブロック崩しを2つ作らせて、片方(Codex 版)を検査していたときの話です。

list_tests を叩くと PlayMode テストが5件見えます。実行します。エラーは出ません。警告も出ません。そして結果が0件でした。

5件

一覧に見えるテスト

list_tests の結果

0件

実際に実行された数

ビルド対象が WebGL のとき

0

エラー・警告

なにも出ない

5/5

Standalone に戻すと

同じコードで全部合格

失敗ではありません。0件0件通ったので、成功扱いです。合格数だけを見ていたら、たぶん気づかずに次へ進んでいました。

何が起きていたか

Claude Code 版Codex 版
list_tests で見える PlayMode テスト5件5件
ビルド対象 WebGL で実行5/5 合格(2.1秒)0件(実行されない)
ビルド対象 StandaloneWindows64 で実行5/5 合格5/5 合格(2.14秒)

コードは関係ありませんでした。テストの中身は両方とも普通に動きます。違っていたのは、テスト用 asmdef の書き方だけです。

原因:asmdef の古い書き方

2つのプロジェクトの PlayMode テスト用 asmdef を並べます(違いのある行だけ)。

動かなかったほう(Codex 版)

{
"name": "Breakout.PlayModeTests",
"references": [
  "Breakout.Core",
  "Breakout.Runtime"
],
"optionalUnityReferences": [
  "TestAssemblies"
]
}

動いたほう(Claude Code 版)

{
"name": "Breakout.Tests.PlayMode",
"references": [
  "Breakout.Core",
  "Breakout.Runtime",
  "UnityEngine.TestRunner",
  "UnityEditor.TestRunner"
],
"overrideReferences": true,
"precompiledReferences": ["nunit.framework.dll"],
"autoReferenced": false,
"defineConstraints": ["UNITY_INCLUDE_TESTS"]
}

optionalUnityReferences: ["TestAssemblies"] は昔の書き方です。今の Unity が Test Framework 経由で Test Assembly を作ると、上の長いほうが生成されます。決め手は3つ

  1. STEP 01

    overrideReferences: true

    参照を自分で決めると宣言する

  2. STEP 02

    precompiledReferences

    nunit.framework.dll を明示する

  3. STEP 03

    defineConstraints

    UNITY_INCLUDE_TESTS のときだけ作る

この3つが揃って、はじめて現在のビルド対象向けにテスト用アセンブリが作られます。

古い書き方でも Standalone では動いてしまうので、普段は気づけません。 ビルド対象を WebGL に切り替えたまま作業していると、そこではじめて黙って0件になります。

なぜ WebGL のときだけ起きるのか

referencesUnityEngine.TestRunnerUnityEditor.TestRunner も書かれておらず、defineConstraints も無いので、このアセンブリを「現在のビルド対象向けにコンパイルする理由」が Unity 側に伝わりません。Standalone のときはたまたま解決できていたものが、WebGL に切り替えた瞬間に解決できなくなった、という形です。

list_tests5件を返し続けたのは、一覧がソース側を見ているからです。一覧に出ることと、実行できることは別物でした。

直し方

メニューの Assets > Create > Testing > Test Assembly Folder で作り直すのが確実です(Test Runner ウィンドウからも作れます)。手で直す場合は、既存の asmdef に次を足します。

{
  "references": ["UnityEngine.TestRunner", "UnityEditor.TestRunner"],
  "overrideReferences": true,
  "precompiledReferences": ["nunit.framework.dll"],
  "autoReferenced": false,
  "defineConstraints": ["UNITY_INCLUDE_TESTS"]
}

optionalUnityReferences は消してかまいません。

直したあとは、ビルド対象を実際の公開先(WebGL など)に切り替えた状態でもう一度実行してください。Standalone で通っても意味がありません。

AI に任せるときのチェック

AI エージェントは「テストは全部通りました」と報告してきます。嘘ではありません。0件0件通っているので、本人の中では正しい報告です。

報告をそのまま受け取る

「テストは全部通りました」「失敗0件」→ 0件でも言える

件数で受け取る

状態ファイルの passedtotal が、期待した件数(今回なら5)と合っているかを見る

だから見るのは件数です。Unity CLI なら結果が Temp/pipeline_test_status.json に書かれるので、そこを読みます。

unity command run_tests --mode PlayMode --async_tests true
# 完了後に Temp/pipeline_test_status.json の passed / total を確認する

まとめ

  • テストが0件でも失敗にはならない。緑に見えるので一番気づきにくい
  • 原因はテスト用 asmdef の古い書き方。overrideReferences / precompiledReferences / defineConstraints が要る
  • 古い書き方は Standalone では動く。WebGL に切り替えたときだけ落ちるので、切り替えた状態で必ず確認する
  • AI の報告は「合格」ではなく「実行件数」で受け取る

FAQ

よくある質問

テストが0件でもエラーにならないのはなぜですか?

テストランナーから見ると「実行対象のアセンブリが存在しない」だけで、失敗ではないからです。0件を走らせて0件成功した、という扱いになります。合格数だけを見ていると気づけません。

list_tests では見えるのに実行されないのはなぜですか?

一覧はソースコード上のテストを拾って出しています。実行は現在のビルド対象向けにコンパイルされたアセンブリが必要で、この2つは別物です。一覧に出ることは実行できることの保証になりません。

古い書き方でも Standalone なら動くのに、直す必要はありますか?

あります。ビルド対象は WebGL やモバイルに切り替えたまま作業することが普通にあり、そのあいだテストが黙って0件になります。気づかないまま「全部緑」で進むほうが危険です。

AI が書いた asmdef が古い書き方になるのはなぜですか?

optionalUnityReferences は昔の Unity で広く使われていた書き方で、学習データにも解説記事にも大量に残っているためだと思います。今の Unity が Test Assembly を作るときに生成する内容とは違います。

どうやって「本当に実行されたか」を確認しますか?

実行結果の件数を見ます。Unity CLI なら Temp/pipeline_test_status.json に結果が書かれるので、passed と total が期待どおりかを確認します。エディターの Test Runner でも、実行後に緑のチェックが実際に付いたかを見てください。

SOURCES

出典

  1. 01Organizing scripts into assembliesUnity Documentationasmdef の役割と、アセンブリの分け方
  2. 02How to create a test assemblyUnity Test Framework「nunit.framework.dll・UnityEngine.TestRunner・UnityEditor.TestRunner への参照が、これはテスト用アセンブリだと UTF に伝える」と書かれている

この記事は役に立ちましたか?

NEXT