Repository navigation
Fix #74: map test items by real class FQN, not filesystem path - #76
Merged
gjsjohnmurray merged 2 commits intoJun 18, 2026
Merged
Conversation
Read the fully-qualified class name from the `Class …` line of every test class while resolving its children, and store it as `ourFqn` on the test item. This decouples the real class identity from the filesystem path under `relativeTestRoot`, which is needed to map the %UnitTest.Manager output back to test items and to build a correct testspec for single-method runs (see intersystems-community#74 for the symptoms).
…s-community#74) When the filesystem layout under `relativeTestRoot` does not mirror the package hierarchy of the test classes, the previous code derived a "class name" from the relative path that diverges from the real compiled FQN written by %UnitTest.Manager. Two consequences: * DebugTracker built its method-item lookup key from the FQN reported in stdout but the test-item ids were path-based, so the lookup returned undefined and run.passed/failed/skipped was never called — every method stayed on "skipped" in the UI. * commonRunTestsHandler reused the same path-based id part as the testcase argument of %UnitTest.Manager.RunTest() for single-method runs, so the manager could not find the class and produced no per-method result. Both call sites now prefer the real FQN from OurTestItem.ourFqn (with the previous behaviour as a fallback when no FQN was parsed).
gjsjohnmurray
approved these changes
Jun 18, 2026
gjsjohnmurray
left a comment
gjsjohnmurray
left a comment
Collaborator
There was a problem hiding this comment.
Very nice. Thanks for contributing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #74.
What
Two related symptoms, both rooted in the test-item id being derived from the filesystem path under
relativeTestRootinstead of from the compiled class FQN:DebugTracker. The tracker built its method-item lookup key from the FQN that%UnitTest.Managerwrites to stdout, while the test-item ids were path-based. When the two diverge (anyrelativeTestRootthat doesn't mirror the package hierarchy), the lookup returnedundefined,run.passed/failed/skipped()was never called, and the UI defaulted everything to "skipped".commonRunTestsHandler. The same path-derived id part was reused as thetestcaseargument of%UnitTest.Manager.RunTest(). The manager could not find a matching class and produced no per-method result, so single-method runs returned nothing either.How
A small extra property
ourFqnonOurTestItem, populated from theClass …line while resolving the.clsfile. Both call sites prefer this FQN and fall back to the previous path-derived value when no FQN was parsed.Verification
Reproduced both symptoms on Windows / IRIS 2025.1.3 with
relativeTestRootset to a directory deeper than the class package root. After the patch:Test…method produces the expected outcome.Commits are split for review: first one wires up the data, second one consumes it in both places.