If you’ve ever worked on a large Unity project, you probably noticed that running tests inside the Unity Test Runner can be painfully slow. You change one line of code, switch to the Editor, wait for it to compile, wait for the domain reload, wait for Test Runner to load, and finally run your tests. This cycle can take anywhere from 15 seconds to several minutes, depending on the project size.

When you are trying to practice Test-Driven Development (TDD) or just want quick feedback on complex algorithms, this friction is a killer.

Even simple unit tests can take several seconds to start because they are executed inside the Unity Editor, which introduces additional overhead such as:

• editor startup and initialization
• domain reloads
• the Mono runtime used by Unity
• test discovery inside the editor environment

For projects with hundreds or thousands of tests, this dramatically slows down the development feedback loop.

Fortunately, there is a much faster approach.

Instead of running tests inside Unity, you can run them using the .NET test runner, which can speed up execution by an order of magnitude.

In this guide you’ll learn how to run Unity tests with .NET and dramatically reduce test execution time. We recently implemented a solution that allows us to run our game logic tests in milliseconds without ever opening Unity. Here is how we did it.

Why Unity Tests Are Slow

The built-in Unity Test Runner executes tests inside the Unity Editor. This means every test run is affected by several layers of overhead:

Editor Environment

Unity initializes editor systems even when they are not needed for unit tests.

Domain Reload

When assemblies change, Unity reloads the AppDomain, which adds extra delay. It can be significant for projects with a lot of asm defs.

Mono Runtime

Unity still relies on the Mono runtime, which is slower than modern .NET runtimes in many scenarios.

Test Discovery

The editor scans assemblies to discover tests before execution begins.

For large projects, these factors can turn a 1-second test suite into a 10–50 second workflow interruption.

The Key Idea: Test Pure .NET Code

The trick is simple:

Keep your core logic independent of Unity so it can run in a normal .NET environment.

This means separating:

Game Logic
↓
Pure C# code (no UnityEngine dependencies)

from:

Unity Layer
↓
MonoBehaviour / UnityEngine code

Once your logic is isolated, you can run tests using the standard .NET tooling, which is significantly faster.

The Implementation

Step 1 — The Project File

We created a separate solution folder HeadlessTests with a standalone .csproj targeting .NET 9.0 at the Unity project root.

The magic happens in the .csproj file. We don’t copy the files; we link them. This ensures that when we modify a file in the test project, we are actually modifying the Unity asset.

Here is the secret sauce in HeadlessTests.csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <IsTestProject>true</IsTestProject>
  </PropertyGroup>

  <!-- Standard Test Packages -->
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0" />
    <PackageReference Include="NUnit" Version="3.14.0" />
    <PackageReference Include="NUnit3TestAdapter" Version="4.5.0" />
  </ItemGroup>

  <!-- The Magic: Linking Unity Scripts -->
  <ItemGroup>
    <!-- Include ALL Runtime scripts -->
    <Compile Include="..\Assets\!_Project\Scripts\Runtime\**\*.cs" LinkBase="Runtime" />
    
    <!-- Include all Tests -->
    <Compile Include="..\Assets\!_Project\Scripts\Tests\**\*.cs" LinkBase="Tests" />
  </ItemGroup>

  <!-- Reference Unity Managed DLLs -->
  <ItemGroup>
    <Reference Include="UnityEngine.CoreModule">
      <HintPath>D:\ProgramFiles\UnityHub\Editor\6000.3.2f1\Editor\Data\Managed\UnityEngine\UnityEngine.CoreModule.dll</HintPath>
    </Reference>
    <!-- Add other modules as needed (UI, Physics2D, etc.) -->
  </ItemGroup>

</Project>

And here’s the project structure in Unity:

Scripts/
├── Editor/
├── Runtime/
│   ├── Core/
│   ├── Data/
│   ├── Logic/
│   │   ├── Interfaces/
│   │   └── Providers/
│   ├── Pyramid/
│   │   ├── Data/
│   │   ├── Logic/
│   │   └── Views/
│   ├── Services/
│   └── Views/
│       ├── MainMenu/
│       └── Shop/
└── Tests/
    └── EditMode/

Most Unity game logic can be tested without the Unity engine if it is structured as pure C# code.

Step 2 — Handling Dependencies

You noticed the Reference block above. Even “pure” logic often relies on Vector3, Mathf, or Debug.Log. By referencing the managed DLLs directly from the Unity Editor installation, we can compile code that uses these types.

Note: Since the Unity Native Backend isn’t running, calls to things like Physics.Raycast or Time.deltaTime might not work as expected. This setup is strictly for logic testing.

Step 3 — Run Tests with dotnet test

Instead of launching Unity, you can now run tests directly from the command line:

dotnet test

This uses the native .NET test runner, which avoids the Unity Editor entirely.

The result is dramatically faster execution.

The Results: Benchmark Example

The difference is night and day. We added a custom logger to measure the exact wait times in Unity versus our headless setup:

Unity Editor (Runtime Assembly Change):

[Compilation] Finished in 0.38s
[Domain Reload] Finished in 3.45s
// 1. Total: ~3.8s wait before you can even open the Test Runner, wait for loading, and only then click "Run Tests"
// 2. Manual steps and the test runner loading ~10-20s
// 3. Test run finished in ~1s

Headless .NET:

Build succeeded in 1.2s
Test summary: total: 20; failed: 0; succeeded: 20; skipped: 0; duration: 0.6s
// Total: 1.8s to build AND run tests.
// Also keep in mind that consecutive builds are even faster.

Benchmark (20 unit tests)
+-------------------+-------------+
| Environment       | Time        |
+-------------------+-------------+
| Unity Test Runner | ~18 seconds |
| .NET Test Runner  | ~2 seconds  |
+-------------------+-------------+

It scales better with bigger projects. I had experience working on a project with >40k unit tests. Running it locally in Unity blocked the editor for a long time.

We can now run dotnet test (or use the “watch” mode) and get instant feedback while refactoring core game mechanics like our Pyramid grid logic or Daily Race systems.

The AI & Iteration Advantage

Beyond personal developer productivity, this infrastructure unlocks a massive advantage for modern AI-assisted workflows. When working with LLMs, the AI can sometimes break working code while fixing bugs. Verifying changes with unit tests is essential, but the friction of the Unity Test Runner makes this slow and manual.

By running tests on the latest .NET without the Unity Editor, AI agents can now run tests themselves to verify their edits and the editor is still available for you to play the game yourself or wire things up in the inspector. This automated verification takes mere seconds, ensuring the AI delivers working code without requiring the developer to manually switch contexts or wait for reloads.

Furthermore, iteration speed is crucial for big teams. Slow Editor performance and assembly reloads can cost hours per week per developer. Moving logic verification outside of Unity isn’t just a “nice-to-have” for small projects, it’s a critical architectural choice for maintaining high velocity in large-scale game development.

CI/CD Benefits

Running tests through the .NET CLI also simplifies automation.

In CI pipelines you can run tests with a single command:

dotnet test

Benefits:

• no Unity license required
• faster CI execution
• simpler build pipelines
• easier integration with test reporting tools

This approach can significantly speed up continuous integration pipelines for Unity projects.

Why This Matters

This approach forces better architecture. To make code testable in this environment, you must decouple your Game Logic from your View Components.

• View (MonoBehaviours): Handles visuals, input, and Unity events. Hard to test here.
• Logic (C# Classes): Handles state, rules, and calculations. Easy to test here.

By enforcing this separation, our codebase becomes cleaner, more modular, and infinitely easier to maintain.

Conclusion

Unity’s built-in Test Runner is convenient, but it is not always the fastest option.

By extracting game logic into pure C# code and running tests with the .NET test runner, you can:

• reduce test execution time dramatically
• speed up development feedback loops
• simplify CI pipelines
• improve overall code architecture

For large Unity projects, this simple architectural change can save hours of waiting every week.

Further Reading On Unit Testing in Unity

• Unity ECS Performance Testing: The Way To The Best Performance
• Unit Testing Made Easy: Unity ECS Best Practices
• Sand Balls Mechanics Implementation: The Best Way To Deform A Mesh In Unity — Part II: MeshData And Optimization
• https://docs.unity3d.com/6000.0/Documentation/Manual/com.unity.test-framework.html

Alexey Merzlikin

Experienced game developer and tech lead with a passion for writing educational content about game development and programming. I have over 10 years of industry experience focused on performance optimization, clean code practices, and robust game architecture. I share regular posts on my Telegram channel about applying software engineering best practices to build high-quality games. My goal is to help other game developers level up their skills.

• Telegram
• GitHub
• LinkedIn
• X