You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on a test controller that is for an extension in a very large mono repo. I'm trying to figure out the best way to handle the scale of testable targets/classes/methods when working the the new vscode.tests API.
One issue I'm currently having is that I feel like creating a test item for each target in the repo is just to much information for a user to deal with. For example, one project has over 2000 testable targets, ranging from around 1 test class/tmethod to 500+ test classes/methods in any given target.
If I were to attempt to create a test item for each and every testable target that feels like the Testing UI gets very crowded.
I currently have 2 tree views, one is the standard Testing UI and the second is a tree view of just the testable targets that you can mark as included/excluded in the Testing UI.
If I could instead mark that my test controller does not want to support the 'Run All Tests' or 'Debug All Tests' I could have just one tree with all the items together and users could use the filtering/excluding/hiding to managing the tree.
I suppose I could instead prompt to user to be more specific if a vscode.TestRunRequest does not have the include set.
The new Testing UI has a much nicer filtering/excluding system than the existing vscode.TreeView provides, so it would be nice to consolidate down to a single tree if possible.
The text was updated successfully, but these errors were encountered:
ashgti
changed the title
Opt a vscode.TestController out of 'Run All Tests' or 'Debug All Tests'
[FR] Opt a vscode.TestController out of 'Run All Tests' or 'Debug All Tests'
Aug 20, 2021
I think that tags support (#129456) is definitely helpful for organizing large sets of tests but I'm still worried that if I registered all the tests and a user hits the 'Run All Tests' they're could end up asking the system to run potentially a few hours worth of tests. That feels like one of those things I'd like to avoid if possible, but maybe I can work around this by just prompting the user to confirm they want to run everything or a smaller subset of tests with a quickpick.
You can also use the passed in CancellationToken in the runTests method to respond to the user asking for the run to be cancelled. You can also make certain profiles the default, or not, which controls what gets run when triggering "run all"
I am working on a test controller that is for an extension in a very large mono repo. I'm trying to figure out the best way to handle the scale of testable targets/classes/methods when working the the new vscode.tests API.
One issue I'm currently having is that I feel like creating a test item for each target in the repo is just to much information for a user to deal with. For example, one project has over 2000 testable targets, ranging from around 1 test class/tmethod to 500+ test classes/methods in any given target.
If I were to attempt to create a test item for each and every testable target that feels like the Testing UI gets very crowded.
I currently have 2 tree views, one is the standard Testing UI and the second is a tree view of just the testable targets that you can mark as included/excluded in the Testing UI.
If I could instead mark that my test controller does not want to support the 'Run All Tests' or 'Debug All Tests' I could have just one tree with all the items together and users could use the filtering/excluding/hiding to managing the tree.
I suppose I could instead prompt to user to be more specific if a
vscode.TestRunRequest
does not have theinclude
set.The new Testing UI has a much nicer filtering/excluding system than the existing vscode.TreeView provides, so it would be nice to consolidate down to a single tree if possible.
The text was updated successfully, but these errors were encountered: