unity-testinglisted

# Unity Testing Decision framework for testing in Unity: when to use EditMode vs PlayMode tests, what is worth testing and what is not, how to structure test assemblies, mocking strategies without third-party frameworks, and how to integrate with CI. ## When to Apply Activate when the conversation involves: - Deciding whether a test belongs in EditMode or PlayMode - Writing a new test class or test assembly - Questions about `[Test]`, `[UnityTest]`, `[SetUp]`, `[TearDown]`, or `TestFixture` - Mocking Unity components or isolating game logic from the MonoBehaviour lifecycle - Setting up assembly definitions for test projects - Running Unity tests in CI (headless, command-line) - Deciding whether something is worth testing at all Do NOT activate for debugging a specific runtime bug without a test reproduction case — that goes to general debugging. Do NOT activate for performance measurement — that goes to `hades:unity-performance`. ## Project Context Check Before making testing recommendations, gather context to match advice to the actual project. 1. **Find existing tests:** - Call `search_by_name("*Test*")` — reveals all existing test files and their location. If the project has no tests yet, the first recommendation is always to establish the assembly structure before writing any test. - Call `search_by_name("*Tests.asmdef")` — finds test assembly definitions. If none exist, any tests are currently compiling into the main runtime assembly and shipping in builds —