MPS, just like any self-respecting IDE, lets you run test cases. The built-in test runner can run plain Java tests, MPS-based node tests, and other kinds of test cases. The framework is user-extensible so you can have MPS treat your concepts as runnable test cases as well.
MPS sees tests as a collection of test cases (represented by the ITestCase interface concept) that contain test
methods (instances of ITestMethod). Note that the terminology is slightly different from some test frameworks which
speak of test suites containing test cases and there is potential for confusion, in particular regarding the term
test case. I will use the terms in their MPS meaning in the rest of this article.
The framework supports tests that are generated into Java classes using JUnit framework (JUnit 4). Tests that are generated into a different language or use a different testing framework are not supported.
Integrating your tests into the MPS framework requires you to implement ITestCase in your test cases and ITestMethod
in your test methods. A single concept can play the roles of a test case and a test method simultaneously (this is the
case for editor tests, as represented by the EditorTestCase concept).
Implementing ITestCase
Test cases must implement the abstract method getTestSet() and override the non-abstract method getTestMethods().
Both methods have to return the list of test methods that this test case contains and you can implement one of the
methods and call it from the other one.
Two other important methods in ITestCase are getClassName() and getSimpleClassName(). They return the fully
qualified class name and the simple class name of the generated test class, respectively. You can either use
getSimpleClassName() in the generator or override the methods to return the class names that you actually generate.
By default MPS will load and run the tests in the MPS process. If you want MPS to fork a separate JVM instead, you have
to either set the canNotRunInProcess property to true or override ITestCase#canRunInProcess().
Implementing ITestMethod
Test methods need to implement the abstract methods getTestName() and getTestCase() which are fairly straightforward
with no hidden obstacles. getTestName() must return the name of the generated test method and getTestCase() should
return the “owning” test case node, often the parent of the test method, cast to the appropriate concept.
A sample
I have uploaded a sample project to GitHub, sample-custom-tests, showing how to implement custom test cases and test methods for a very simple testing language. Here is what it looks like when you run these tests in MPS:
