Correct API to resolving module-reference from within a NodesTestCase

I have a NodesTestCase where I try to resolve a module. This has worked before via:

return (solution) module-reference/my.module.namespace/.resolve(MPSModuleRepository.getInstance());

The module I want to load is in the same project as the module that contains the test case. When I run above code from within MPS, it still works.
When I run it from my console, it cannot resolve the module reference anymore (the resolve method returns null).
I tried different other ways to resolve the module-reference. For example, via `project.getModules()` or `project.getProjectModules()`, both returning empty lists when I run the test from console, but both work fine when run from within MPS.

I also tried `project.getRepositry().getModules()`: When run from within MPS, this returns a boatload of modules (903). When run from console, it is still 548 modules. However, the one I am looking for is not part of the result when run from console.
In other words, when I call `project.getRepositry().getModule(module-reference/my.module.namespace/.getModuleId())` I get the desired result only when I run it from within MPS, not from console.
Notive that this "magic" `project` variable is different when run from console. From within MPS, I have two instances of MPS open: (1) my language engineering project, and (2) a second project with sandbox-solutions and the test solution from where I want to load one of the sandbox-solution modules. So, when I print `System.out.println(" " + project.getProjectFile().getAbsolutePath());` from MPS, project points to my "engineering workspace" (not what I would expect!), whilst it points to my "sandbox workspace" when run from console.
Can somebody shed some light for me on this behavior? How can I resolve a module-reference correctly from within a NodesTestCase?

Comment actions Permalink

MPS shall use the project you specify with TestInfo root, the one that resides next to your tests. This doesn't apply if you run tests in-process, in this case MPS would ignore TestInfo settings.

The proper way to access test modules is to use 'project' (ProjectExpression concept from j.m.lang.test) and its repository, i.e. 'project.getRepository()'. Technically, you have to distinguish between modules that are deployed/executed for your MPS instance, and source modules constituting MPS project. Latter could get compiled and deployed, and MPS doesn't make clear distinction between the two now. In fact, for the time being, all modules (both deployed and source) are visible through global MPSModuleRepository. However, its use is discouraged as the distinction between deployed and source modules are likely to become reality in upcoming MPS releases.

Nevertheless, with your present MPS and single global module repository, the cause for your issue is elsewhere. The module you try to resolve just didn't get neither into set of 'executed' modules, nor into test project with sources modules (the one indicated with TestInfo). To get the module into set of deployed modules, you'll need to mention it in the build script for your tests (I assume you've got build project with 'module-tests' plugin and 'test modules configuration' to run your tests from console).

Comment actions Permalink

You are right, we figured out earlier today that the Testinfo path was wrong. Just hadn't had time to post the good news here.
Thank you.


Please sign in to leave a comment.