Testing a Unity game without a Unity license: dotnet stubs in CI

The indie CI problem

A Unity license for CI requires Unity Build Server or an equivalent seat — easily several hundred euros a month for small indie studios. For a free-to-play mobile arcade runner like ORBYX that is a disproportionate fixed cost. At the same time every developer wants the same baseline guarantee: a PR that fails before it is merged.

The approach: dotnet test against Unity stubs

The choice made in ORBYX is to abstract the Unity layer where that is meaningful and run all pure logic against dotnet test — without Unity in the pipeline. Concretely, three sharp layers:

• Unity stub interfaces — for classes that lean heavily on Unity (MainMenu, GameOverScreen, GameHUD), stubs replace the Unity bits with a testable interface.
• Pure logic modules — game balance, scoring, mode detection, achievements and theme difficulty live in pure C# modules with no Unity types in their public API.
• dotnet test in pipeline — the pipeline runs dotnet test on a PHP-Apache + ext-redis image (no Unity) and returns a red/green result within two minutes.

The four-step quality gate

On top of unit tests, every ORBYX build runs four static gates before a PR can go green:

1. quality-gate.sh — brace balance, namespace integrity, duplicate classes, old Input API calls, lingering TODO markers.
2. Project validation — required files are present, scene GUIDs are correct, no orphaned .meta files.
3. Asset validation — required textures are present, meta completeness, no oversized files.
4. Pure logic unit tests — dotnet test against the Unity stubs.

What stays out of scope

This approach does not replace integration tests in a real Unity environment. What remains hard to test without a license: scene loading, camera paths, input systems, physical collisions with Rigidbody. Those tests still run locally in the Unity editor, not in CI. That is a deliberate split: the pipeline delivers what it can deliver cheaply (fast structural and logical signals), the editor delivers what only it can deliver (integration and visual confirmation).

When this is worth copying

The pattern works for Unity projects where most of the game logic can live outside Unity types. In ORBYX that means: rubber-banding for VS Computer mode, drafting AI, theme difficulty curves, daily challenge seed rotation, achievement state — all pure C#. For a 3D action RPG with deep MonoBehaviour coupling the same pattern pays off less. For an indie arcade runner from a small indie studio it is the right ratio: no Unity Build Server, two-minute CI feedback, and a test suite that only grows as the logic grows.