unity-testability

Identify extractable Unity MonoBehaviour logic for pure C# unit testing.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/mandexonla/Top-Down-Template --skill unity-testability-mandexonla
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: unity-testability
Source: https://github.com/mandexonla/Top-Down-Template/tree/main/.codex/skills/unity-skills/skills/testability
Command: npx skills add https://github.com/mandexonla/Top-Down-Template --skill unity-testability-mandexonla

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Helps Unity developers decide which code belongs in Unity-facing MonoBehaviour and scene context versus pure C# modules so core logic becomes reliably unit-testable, reducing coupling to scene state and fragile PlayMode tests.

Core Features & Use Cases

  • Identify extractable logic: Point out algorithms and rules that can run without Transform, GameObject, or other scene state and should be moved into plain C# classes.
  • Preserve Unity-facing responsibilities: Mark thin MonoBehaviour responsibilities such as wiring, input translation, and scene binding that should remain Unity-bound.
  • Design seams and interfaces: Recommend dependency injection points, interfaces, and seams for mocking scene or engine interactions.
  • Test suggestions: Propose candidate EditMode tests for pure logic, and candidate PlayMode tests for scene-dependent behavior while avoiding unnecessary abstraction for tiny, scene-bound scripts.

Quick Start

Analyze this Unity MonoBehaviour, list what to extract into pure C#, propose seams/interfaces for injection, and outline candidate EditMode and PlayMode tests.

Frequently Asked Questions about unity-testability

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make Unity MonoBehaviour code unit-testable?

To make MonoBehaviour code testable, isolate pure logic that does not depend on Transform or GameObject scene state into plain C# classes, leaving only thin wiring and input translation in the MonoBehaviour.

When should I use EditMode tests versus PlayMode tests in Unity?

Use EditMode tests in Unity for pure C# logic without scene dependencies, and PlayMode tests for behavior that requires GameObject or scene context. Separate pure logic from MonoBehaviour to run reliable EditMode tests without fragile scene setups.

What is the best way to isolate Unity-facing code for dependency injection?

The best way to isolate Unity-facing code for dependency injection is to design seams and interfaces around scene interactions. Inject interfaces for engine dependencies to mock interactions and test pure C# modules independently of the Unity scene context.

Do I need to extract all MonoBehaviour logic into pure C# for unit testing?

You do not need to extract all MonoBehaviour logic into pure C# for unit testing. Avoid unnecessary abstraction for tiny, scene-bound scripts and preserve Unity-facing responsibilities like scene binding to prevent over-engineering your project architecture.

Why are my Unity PlayMode tests fragile and how can I fix them?

Unity PlayMode tests are fragile when core logic is tightly coupled to scene state. Fix them by moving algorithms into testable pure C# modules, reserving PlayMode tests strictly for scene-dependent behavior and dependency-injected seams.