Customizing unit tests in the VS Code extension #67
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| case TestStatus.Failed: { | ||
| const messages: vscode.TestMessage[] = []; | ||
|
|
||
| if (methodResult.failures?.length) { | ||
| for (const failure of methodResult.failures) { |
There was a problem hiding this comment.
When handling a failed method result, the branch at these lines only populates messages from methodResult.failures and never adds methodResult.error before calling testRun.failed. If the legacy runner returns an error without any failure locations (e.g., a class-level error mapped to a method), the method is marked failed with an empty message, so the actual error text never appears in the Test Explorer, making failures hard to diagnose.
Useful? React with 👍 / 👎.
Summary of Customizations
Changes
Added inline status decoration
Each test method now shows a clean inline decoration (status + duration) without modifying the file contents.
Improved test output mapping
Test output is now properly grouped per method and attached to the correct TestItem, ensuring that selecting a method in Test Results shows its console output and summary line.
Removed inline output artifacts
Eliminated the issue where summary/output lines were being rendered inside the editor along with decorations.
Added summary message for classes with failures
When a class-level result contains failures, a readable summary message is generated listing which methods failed.
Workspace root grouping
Fixed the issue where multiple test roots matched by wildcard patterns (*) produced duplicate namespace items (e.g., many DESENV75 entries).
Now all roots belonging to the same workspace/namespace are grouped under a single root node, while still respecting all configured relativeTestRoots.