Unit Test System in the InterSystems iris

For VS Code unit testing in InterSystems IRIS 2023.3+, the key points are:

1. Your server must be IRIS 2023.3 or later. [1][2]
2. The VS Code setting must be objectscript.unitTest.enabled = true. The setting name shown in the docs is objectscript.unitTest.enabled. [1][2]
3. If you are using a client-side workspace, you must also configure objectscript.unitTest.relativeTestRoots to the relative path(s) where your test classes are stored. The extension scans those directories for classes extending %UnitTest.TestCase. [1][2]
4. The extension discovers only classes that extend %UnitTest.TestCase. [1][2]
5. The namespace’s ^UnitTestRoot must be set to an existing local filesystem directory. For the built-in ObjectScript extension, this is required so the extension can execute tests using %UnitTest.Manager, but the extension does not use the value of ^UnitTestRoot to locate the tests. [1][2]

So if your tests are not appearing in VS Code, the most likely issue is that VS Code is not scanning the location where your test classes are stored. In a client-side workflow, it only looks under the folders listed in objectscript.unitTest.relativeTestRoots. [1][2]

How test discovery works:

• Client-side workspace: tests are found only in the directories specified by objectscript.unitTest.relativeTestRoots. [1][2]
• Server-side workspace: tests are found in workspace folders that are configured to include them. For example, if a server-side folder includes a project containing test classes, they appear; if it only includes something like filter=*.mac, they will not. [1][2]

Also, test classes in directories whose names begin with _ are ignored, except for the autoload directory case. [1][2]

[!NOTE]

You cannot run unit tests within the %SYS namespace of an InterSystems server. [1][2]

[!NOTE]

If you are editing on the client-side and you export a test class from the server using the ObjectScript Explorer, the extension places that class within a /src/ folder on the client-side workspace, regardless of where the test is stored on the workspace. This may result in duplicate copies of a class in two client-side locations. [1][2]

If you want to use the separate InterSystems Testing Manager extension instead of the built-in ObjectScript unit test support, its setup is different:

• It requires a /_vscode web application on the server. [3]
• It requires ^UnitTestRoot to be set to a path based on that web application physical path, with \<NAMESPACE>\UnitTestRoot appended. [3]
• In client-side mode, its default test location is internal/testing/unit_tests, unless you override it with intersystems.testingManager.client.relativeTestRoot. [3]

For your case on 23.3, to create and run unit tests in VS Code with the built-in support:

• create classes extending %UnitTest.TestCase
• make sure each test method is in such a class
• enable objectscript.unitTest.enabled
• set objectscript.unitTest.relativeTestRoots to the folder containing those test classes if you are working client-side
• ensure ^UnitTestRoot points to an existing directory
• do not use %SYS namespace [1][2]

If ##class(...).RunTest() runs but the VS Code test explorer is empty, that fits the documented behavior that discovery depends on workspace scanning, not on ^UnitTestRoot. [1][2]

Sources: