Repository navigation
Test error hides path to file on Test Results tab #5534
Description
Describe the bug
When a test errors, the Test Results tab stops showing the path to the file and that can make sibling-classes tests harder to debug to find which one broke.
To Reproduce
Steps to reproduce the behavior:
- Clone https://github.com/FMorschel/test_repro
- Run the dart tests
Expected behavior
The path to the file should show up on the Test Results tab even when errors occur.
Screenshots
The same tests in Python (pytest) and JS (jest):
Please complete the following information:
Workspace Environment
Dart Code extension: 3.113.20250602
Flutter extension: 3.113.20250603 (not activated)
App: Visual Studio Code
App Host: desktop
Version: win 1.100.3
Workspace type: Dart (LSP)
Workspace name: test_repro
Dart (3.8.0): C:\Users\felip_0vh5fa6\.puro\shared\caches\18818009497c581ede5d8a3b8b833b81d00cebb7\dart-sdk
Flutter (3.32.0): C:\Users\felip_0vh5fa6\.puro\envs\stable\flutter (No device)
Output from 'dart info'
C:\Users\felip_0vh5fa6\.puro\shared\caches\18818009497c581ede5d8a3b8b833b81d00cebb7\dart-sdk\bin\dart.exe info
If providing this information as part of reporting a bug, please review the information
below to ensure it only contains things you're comfortable posting publicly.
General info
- Dart 3.8.0 (stable) (Wed May 14 09:07:14 2025 -0700) on "windows_x64"
- on windows / "Windows 11 Pro" 10.0 (Build 26100)
- locale is pt-BR
Project info
- sdk constraint: '^3.8.0'
- dependencies:
- dev_dependencies: lints, test
Process info
| Memory | CPU | Elapsed time | Command line |
|---|---|---|---|
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe | |
| 0 MB | -- | dart.exe |
Activity
DanTup commentedon Jun 5, 2025
Looking at the screenshot again, I think the reason it still shows up for them might be that they are sticking it at the start of the failure message:
I'm not sure how to run your Jest test, but I suspect it has similar.
And while this works, I'm not sure it's a good approach, because it means you wouldn't see the failure message in the error bubble:
Or at least, it would be prefixed with the filename/path.
I feel like it would be better if VS Code provided better options here, or at least a tooltip with the location in so it's not hard to find for failures.
I wonder if @connor4312 has any thoughts/opinions on this before we file an issue there?
FMorschel commentedon Jun 5, 2025
I used this extension for it https://marketplace.visualstudio.com/items?itemName=Orta.vscode-jest
I don't code with JS that often, so if there is an official one, I'm unaware. This one worked just fine for me.
Ohh, I missed that, yes, not ideal.
What are we sending? I presume we still send the test name with the groups, I presume, for differentiating them, right? Or do they get a different internal ID?
DanTup commentedon Jun 5, 2025
We create a
TestItemto represent the test in the model (these are a tree, with suites at the top level and tests as the leaf nodes), and when a test fails we create aTestMessagewith the text for the failure (in the cases where we can extract expected/actual we also supply them).It appears that when there is a failure
TestMessagethen VS Code shows that as the text next to the node, but if there is not, then it appears to show the text from each parent node joined together with a left-pointing arrow (this is useful text to give context of where the test is, but it's not shown for failures).testing: preserve path on failed cases
connor4312 commentedon Jun 5, 2025
Yea I think we should just fix this in VS Code. Created a draft PR, will merge it after our current release work finishes.
DanTup commentedon Jun 5, 2025
@connor4312 perfect, thank you! 🙂
testing: preserve path on failed cases (#250757)
FMorschel commentedon Jun 13, 2025
I see the fix has been merged, and this will get fixed on stable!
Just as a note to whoever might be interested: this is even more confusing when the error is an assertion/throw and the output starts with a path.
DanTup commentedon Jun 16, 2025
I can see this in Insiders now, looks reasonable to me. Thanks @connor4312!