Unityのテストが「0件」で通る:asmdefの古い書き方が原因だった
list_tests では5件見えているのに、実行すると0件。テスト用 asmdef の書き方が古く、ビルド対象が WebGL のときだけテスト用アセンブリが作られていませんでした。同じ手順で2つのプロジェクトを比べた実測と、直し方です。
公開 2026年9月16日
この記事の要点5 points
- PlayMode テストが1件も実行されないのに、失敗もエラーも出ない。 「合格」と見分けがつかないのが一番危ない。
- 原因はテスト用 asmdef が古い書き方(optionalUnityReferences だけ)で、ビルド対象が WebGL のときテスト用アセンブリが作られていなかった。
- ビルド対象を StandaloneWindows64 に戻したら、同じコードで 5/5 合格した。
- 同じ WebGL 状態でも、新しい書き方の asmdef を持つプロジェクトは 5/5 実行できた。 asmdef の差だけで再現する。
- 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つ。
STEP 01
overrideReferences: true
参照を自分で決めると宣言する
STEP 02
precompiledReferences
nunit.framework.dll を明示する
STEP 03
defineConstraints
UNITY_INCLUDE_TESTS のときだけ作る
古い書き方でも Standalone では動いてしまうので、普段は気づけません。 ビルド対象を WebGL に切り替えたまま作業していると、そこではじめて黙って0件になります。
なぜ WebGL のときだけ起きるのか
references に UnityEngine.TestRunner も UnityEditor.TestRunner も書かれておらず、defineConstraints も無いので、このアセンブリを「現在のビルド対象向けにコンパイルする理由」が Unity 側に伝わりません。Standalone のときはたまたま解決できていたものが、WebGL に切り替えた瞬間に解決できなくなった、という形です。
list_tests が5件を返し続けたのは、一覧がソース側を見ているからです。一覧に出ることと、実行できることは別物でした。
直し方
メニューの 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件通っているので、本人の中では正しい報告です。
報告をそのまま受け取る
件数で受け取る
passed と total が、期待した件数(今回なら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
出典
- 01Organizing scripts into assembliesUnity Documentationasmdef の役割と、アセンブリの分け方
- 02How to create a test assemblyUnity Test Framework「nunit.framework.dll・UnityEngine.TestRunner・UnityEditor.TestRunner への参照が、これはテスト用アセンブリだと UTF に伝える」と書かれている
この記事は役に立ちましたか?
NEXT
あわせて読む
AIにUnityのテスト・動作確認・ビルドまで回させる手順
Unity CLI の run_tests / editor_play / capture_game_view / build を使って、人が画面を触らずにテストと動作確認とWebGLビルドを回した手順を、実際のコマンドと所要時間つきで残します。
Claude CodeとCodexに同じ仕様書でブロック崩しを作らせた
同じ仕様書1枚を Claude Code(Opus 5)と Codex(GPT-5.6 Sol)に渡し、Unity 6.6 でブロック崩しを作らせて比べました。かかった時間、テストの数、詰まった場所、消えた利用枠まで、実測値をそのまま載せています。
WindowsでAIにUnityを操作させて踏んだ落とし穴14個
Unity CLI と Claude Code・Codex で実際にゲームを1本作る間に踏んだ問題を、症状・原因・対処の形で残します。PowerShell で引用符が消える、テストが0件になる、PC のスリープで打ち切りタイマーが効かない、など。