DISCLOSURE: LLM-GENERATED TEXT
Problem
The Tests/Editor suite is compiled by no CI lane, so a test there is
only checked when a real editor runs it. On a host whose editor is
unreachable - which is the state this repository is usually in - a test
that cannot compile, or an assertion that cannot pass, lands green.
#192 shipped both. One omitted a using System; for Array.Empty, and
one compared a three-element array against a two-element one. Three
adversarial reviews found them; a compile of the file found the first in
seconds.
What works today
Scratch under .artifacts/testcompile: compile Runtime/** plus one
Tests/Editor file against the same pinned 2021.3.33 reference
assemblies npm run compat:check uses, stand in only for the seven
Mathf entry points the icall blocks, and invoke the test methods by
reflection. NUnitLite discovery loads every type in the assembly and
trips the icalls, so the runner calls the methods it wants directly.
That runs 11 of the 15 sanitizer methods. The four that fail call
CommandPaletteUI.ClampOutputLength, which needs a live
UnityEngine.Object; the subject is the engine, not the code.
Fix
Add it as a CI lane and widen it, so the check exists for everyone
instead of for whoever happened to need it this session:
- A
Tests/Editor project in tooling~/compat/, run by a workflow on
the Tests/Editor/** and Runtime/** path filter. Compile coverage
alone would have caught the missing using.
- The method runner as a
NUnitLite entry point, or a filter that
selects only the engine-independent fixtures. Either way, a red
fixture must fail the job, so a broken assertion cannot land.
- A documented list of what still needs the editor, so widening is a
checklist rather than a guess.
Note
The stand-in is a double-edged tool: it lets a suite that should fail
pass silently. Every fixture that needs a live UnityEngine.Object has
to be excluded by name, or the lane reports green for a test that never
ran.
DISCLOSURE: LLM-GENERATED TEXT
Problem
The
Tests/Editorsuite is compiled by no CI lane, so a test there isonly checked when a real editor runs it. On a host whose editor is
unreachable - which is the state this repository is usually in - a test
that cannot compile, or an assertion that cannot pass, lands green.
#192 shipped both. One omitted a
using System;forArray.Empty, andone compared a three-element array against a two-element one. Three
adversarial reviews found them; a compile of the file found the first in
seconds.
What works today
Scratch under
.artifacts/testcompile: compileRuntime/**plus oneTests/Editorfile against the same pinned 2021.3.33 referenceassemblies
npm run compat:checkuses, stand in only for the sevenMathfentry points the icall blocks, and invoke the test methods byreflection. NUnitLite discovery loads every type in the assembly and
trips the icalls, so the runner calls the methods it wants directly.
That runs 11 of the 15 sanitizer methods. The four that fail call
CommandPaletteUI.ClampOutputLength, which needs a liveUnityEngine.Object; the subject is the engine, not the code.Fix
Add it as a CI lane and widen it, so the check exists for everyone
instead of for whoever happened to need it this session:
Tests/Editorproject intooling~/compat/, run by a workflow onthe
Tests/Editor/**andRuntime/**path filter. Compile coveragealone would have caught the missing using.
NUnitLiteentry point, or a filter thatselects only the engine-independent fixtures. Either way, a red
fixture must fail the job, so a broken assertion cannot land.
checklist rather than a guess.
Note
The stand-in is a double-edged tool: it lets a suite that should fail
pass silently. Every fixture that needs a live
UnityEngine.Objecthasto be excluded by name, or the lane reports green for a test that never
ran.