Change:
return stateDelta; } <ins> let inSameLocation = false; </ins> if (a instanceof TestItemTreeElement && b instanceof TestItemTreeElement && a.test.item.uri && b.test.item.uri && a.test.item.uri.toString() === b.test.item.uri.toString() && a.test.item.range && b.test.item.range) { <ins> inSameLocation = true; </ins> const delta = a.test.item.range.startLineNumber - b.test.item.range.startLineNumber; if (delta !== 0) { return delta; } } <del> return (a.sortText || a.label).localeCompare(b.sortText || b.label); </del> <ins> // If tests are in the same location and there's no preferred sortText, // keep the extension's insertion order (#163449). return inSameLocation && !a.sortText && !b.sortText ? 0 : (a.sortText || a.label).localeCompare(b.sortText || b.label); </ins> } }

Discussion:
Type: <bBug</bIf you look at the picture... ! can see that tests in test explorer are sorted by parameters. Due to the sorting, when we have a test with lot of parameters, we cannot distinguish which one failed. To find out failed test, we have to comment all parameters and than uncomment one by one. If I pres "Go to Test" button, on any parameter, it leads me to the line, which means it is not usable at all. It would be usable if "Go to Test" points to test parameters. For example if I press it on the line from the picture above, the cursor should be positioned at line 12, not 7. As it is right now, you can freely remove "Go to Test" from parameters, and just leave the one on the root () because it is useless. Either stop sorting tests in test explorer (at least parameterized tests) or make "Go to Test" to go to selected parameters. Extension version: 2022.16.0 VS Code version: Code 1.72.1 (, 2022-10-10T17:22:48.346Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 <!-- generated by issue reporter --
This is a limitation of itself. It does not provide the line number for the parameter. So there is no way for us to find it accurately in all scenarios. This will require work on pytest itself and then we can add that. Created to track this request. This is handled by the Testing UI. So moving this to VS code.
To make things more interesting you have two different orders: !
All pytest parameterized tests have the same structure in a decorator: a string parameter and a list of tuples. If you introspect decorator, that should be enough isn't it?
If you introspect decorator, that should be enough isn't it?

Pytest has several extensions where the parameters are generated on the fly, the params may be wrapped by an id instead of representing them as string. You could even write out tests like this: We would want itself to provide us the line numbers. This way, pytest or any of its extensions can decide what is right for their scenario. We can discuss that here: This issue here can track the Test Explorer UI part of the problem.
In the mean time, the only solution is to comment and uncomment tests to find out the one that has failed, isn't it?
The failed tests should be marked as failed, so you could just use the command from the pallet to run just the failed ones. But, for now there is no way to go to the exact parametrized value that triggered it.
Can you please turn on stop watch and tell me which parameters has failed and provide result here? ! ! Now consider that you are testing integration with lots of branches, lots of parameters (here we have only two but still it is not easy, you have to reach to the dictionary, with key find value, now it is at the same screen but usually it is on the very beginning of the file... I believe that you have got the picture).
I am just curios, how you know which test parameters to use if "Debug Test" button is pressed? !
We don't. Every test item you see in the test explorer there has a generated id. When you click the debug button, we ask pytest to run the test with that ID equivalent to . You can see the generated id yourself by running .
Let's conclude this discussion: sorting, you need pytest id sorting that is depicted on second picture from the very beginning you can't do anything to parameter is not possible, but you opened for that So, everything will stay as it is right now. If that is the true, please close this issue.
In this I think there is some issue. The order that we want there is that one that pytest gives. Things should not get reordered unless you have selected a sort order in the UI. I think the sort order provided by the extension should be preserved. Is there something that is re-ordering these items
Where I can select a sort order in UI?
You can see that here: !
Thanks
Do you plan to do anything with this issue?
PR's welcome
Verified.