Mps Tests

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, generator, migrations). 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.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.
• Prefer invoke action <ActionId> over raw press <chord> for Enter/Tab/etc. in EditorTestCase — PressKeyStatement may bypass the named-action dispatcher used by the production editor. Editor actions live in r:9832fb5f-2578-4b58-8014-a5de79da988e(jetbrains.mps.ide.editor.actions).
• 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.

Common-Path Workflow

When asked to "write tests" for an MPS language feature:

1. Decide the test type. Typesystem / scope / constraint → NodesTestCase. Intention / action / keystroke → EditorTestCase. Migration → MigrationTestCase. Runtime helper → BTestCase. Generator output equivalence → NodesTestCase + assertNodesMatch. See references/test-types.md.
2. Find or create the test model. Prefer extending an existing @tests model in the language's adjacent test Solution; only create a new one if no suitable Solution exists.
3. Add the test root with mps_mcp_create_root_node using the concept ref from references/concept-identifiers.md, then populate nodes / code / etc. with mps_mcp_update_node. Use mps_mcp_parse_java_and_insert to drop a Java/BaseLanguage snippet into a TestNode.
4. Mark assertions using the appropriate annotation concept (see references/nodes-test-case.md and references/editor-test-case.md). For prototypes, open the model in MPS and use the Alt+Enter intentions ("Add Node Operations Test Annotation", "Add Test Node Label", "Mark Caret Position") — they create the right annotations without hand-building blueprints.
5. Validate with mps_mcp_check_root_node_problems on the new root.
6. Run. Register a JUnit Tests config via mps_mcp_create_run_configuration — modelReference for the @tests model, or one test root in nodeReference when iterating on a single test — and launch it with execute_run_configuration, or ask the user to run it in MPS.

Where Test Models Live

If the only goal is plain JUnit on hand-written Java/Kotlin (no MPS-specific assertions), prefer a regular module test source root rather than a @tests model — see mps-distribution-build for how BTestCase-based MPS test modules are packaged.