MPS: Skill for Claude Code

Writing Tests in MPS Models

Loading companion skills

Companion names in this skill are lazy dependencies: load only those relevant to the current task. If this skill came from an MCP server, use the host's skill loader to resolve the companion's unique discovered entry URI on the same host-assigned originating server. If the host has no server-backed skill loader, stop and report that limitation; do not silently fall back to a filesystem copy. If this skill came from a filesystem catalog, load the named sibling from that same catalog at <skills-root>/<skill-name>/SKILL.md, even if remote skill loaders are also available. Do not invent a tool name or server endpoint.

MPS ships a dedicated test language — jetbrains.mps.lang.test — for testing language artefacts (typesystem, scopes, constraints, dataflow, editor, migrations), and jetbrains.mps.lang.test.generator for generator tests. Plain JUnit-style tests against runtime classes use jetbrains.mps.baseLanguage.unitTest (the BTestCase concept).

A test is a root node living in a model whose stereotype is tests (pass moduleName: "<hosting solution>" and modelName: "<name>@tests" to mps_mcp_create_model; the on-disk file ends in @tests.mps). See aspect-model-stereotypes.md for all model identifiers. The test model lives in a Solution module carrying the tests facet, not in the language module itself, so it can depend on the language under test plus arbitrary runtime libraries.

This skill is the reference for what to put in a test model and what each test type means. For the mechanics of creating/modifying nodes via MCP, see mps-model-manipulation and the mps_mcp_* tool docs. Documentation: https://www.jetbrains.com/help/mps/testing-languages.html. Source: plugins/mps-testing/languages/lang.test/.

Critical Directives

• The test model must carry stereotype tests (file name …@tests.mps). Without it, roots compile but are not discovered as JUnit tests.
• Used languages on a test model: jetbrains.mps.lang.test, jetbrains.mps.baseLanguage.unitTest, the language(s) under test, plus jetbrains.mps.baseLanguage, jetbrains.mps.baseLanguage.collections, jetbrains.mps.baseLanguage.closures (closures in editor-test helpers such as EditorTestUtil.runWithTwoStepDeletion), jetbrains.mps.lang.smodel, jetbrains.mps.lang.text as needed by assertion code.
• The containing Solution must carry the tests facet. Languages and Generators don't compile the test classes, so the test root must live in this dedicated Solution. Create it via mps_mcp_create_module(type="solution", …, facets="[\"tests\"]"); the response is self-describing — {"data":{"kind":"Solution","facets":["java","tests"],"loadExtensions":"NotAvailable",…}} confirms the kind without a follow-up call. For an existing Solution, attach the facet via mps_mcp_update_module_facet(facetType="tests", enabled=true) and verify with mps_mcp_get_project_structure(startingPoint="…") (its facets array will include "tests").
• The testMethods role declares NodesTestMethod, which is abstract — instantiate SimpleNodeTest (c:8585453e-6bfb-4d80-98de-b16074f1d86c/1225978065297). Inserting raw NodesTestMethod fails with "Abstract concept instance detected".
• Inside snippets, TestNodeAnnotation labels are only resolvable via TestNodeReference from test-method bodies. For in-snippet references (e.g. setting RoutineCall.routine) use the target node's own name property (resolved through the language's scope) or a persistent r: node ref, never the label name.
• A test that checks a stored node (a sample in another model, as stored, not a copy inside the test) reaches it with node-ptr/<name>/.resolve(project.getRepository()) after importing that node's model into the test model, never with a search for its name: the literal follows renames and shows in Find Usages. Blueprint in references/link-and-concept-literals.md in the mps-model-manipulation skill root after loading that companion skill from the same origin.
• A test written first must fail first, for the reason the change addresses. Run it before the change and read the failure. In an editor test, a bad caret, cell id or missing import is a test bug, so fix it and run again. In a generator test, the red is a mismatch naming what the change addresses (for a rule not yet written in a made generator, the unchanged input root); Node: null vs <root> means no generator ran (mps_mcp_generation PLAN shows NO_GENERATORS: create and MAKE the generator first) or generation failed (IDE log), and an AssumptionViolatedException is a setup bug. A test that already passes either tests nothing or shows the behaviour already exists, so strengthen the test or drop the change. Whether to write a test first at all is decided by the first Critical Directive of mps-aspect-editor-menus-and-keymaps (editor tests) or mps-aspect-generator (generator tests).
• Prefer invoke action -> <Name> over raw press <chord> for Enter/Tab/etc. in EditorTestCase — PressKeyStatement may bypass the named-action dispatcher used by the production editor (exception: press ENTER applies an open completion menu's item). Editor actions live in r:9832fb5f-2578-4b58-8014-a5de79da988e(jetbrains.mps.ide.editor.actions). Undo, Redo, Copy, Cut and Paste are platform actions: invoke action by id: $Undo ($Redo, $Copy, $Cut, $Paste). Never reach UndoManager, FileEditor or DataManager.getInstance() from a test — it fails in a test JVM (CI).
• Generator output is tested with a GeneratorTest root (jetbrains.mps.lang.test.generator), which generates an input model and matches the result against an expected model. There is no GeneratorTestCase in jetbrains.mps.lang.test, and a NodesTestCase that drives generation is the wrong tool. Mark the input and expected models "Do not generate" (mps_mcp_update_model SET_DO_NOT_GENERATE) before the first make. See references/generator-test.md.
• For an empty list role, target empty_<role> for the caret — not refNodeList_<role> (the latter is the populated wrapper cell).
• Never edit test_gen/ or classes_gen/ — those are regenerated.