Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing API: "Retired" TestItem "state" #134970

Closed
matepek opened this issue Oct 13, 2021 · 15 comments
Closed

Testing API: "Retired" TestItem "state" #134970

matepek opened this issue Oct 13, 2021 · 15 comments
Assignees
Labels
api-finalization feature-request Request for new features or functionality testing Built-in testing support verification-needed Verification of issue is requested verified Verification succeeded
Milestone

Comments

@matepek
Copy link

matepek commented Oct 13, 2021

There was a feature request: #115086

In case of the final API I don't know how to implement it. I cannot find the feature.
I guess it is removed. I think my users would love the feature.

Would you help me on this @connor4312 ?

@connor4312 connor4312 added feature-request Request for new features or functionality testing Built-in testing support labels Oct 13, 2021
@connor4312 connor4312 added this to the Backlog milestone Oct 13, 2021
@matepek
Copy link
Author

matepek commented Oct 14, 2021

Also there is a feature related to this which might worth to be considered. Test Explorer had an "auto-run" option.
If it is checked and there is a retired event about a test then a test-run will be created for those. (in case of test-explorer)

I can manually add option like this but it is a nice feature I believe.
A "Run retired/stale tests only" command can be useful also... maybe...

@connor4312
Copy link
Member

The Test Explorer UI extension used retired states to drive autorun. I would instead like to have the extension drive its auto autorun (#134941), so retired states are no longer necessary for this use case and I'm not sure whether I want to bring them back.

@matepek
Copy link
Author

matepek commented Oct 14, 2021

The retired state basically an indicator in the tree view and the user can see if a test's result is outdated.
In case of c++ test executables I can detect the change of the moditime and mark all the tests coming from the executable as outdated. I love this feature. The way ho it does it that the retired tests' icons are 20% transparent I think. (Tooltip also could indicate it) Or maybe if I could just clear the state but that is less useful because it is nice to know what was the previous state of the test.

The auto-run is built upon this indeed. I can implement it easily if you don't wish to add it.
Regarding to this: It would be nice if we could contribute to the "..." menu. (adding new items. In this case: one with a checkbox)

@connor4312
Copy link
Member

You can contribute to all test menus like any other menu 🙂 https://code.visualstudio.com/api/references/contribution-points#contributes.menus

@matepek
Copy link
Author

matepek commented Nov 20, 2021

Hello,
Any news on this front?

2 similar comments
@matepek
Copy link
Author

matepek commented Dec 3, 2021

Hello,
Any news on this front?

@matepek
Copy link
Author

matepek commented Oct 15, 2022

Hello,
Any news on this front?

@xisui-MSFT
Copy link
Contributor

Hi @connor4312, is there a way to mark some tests as outdated without auto rerun? In our extension, we would like to mark some tests as outdated in cases like some configs change, but we prefer not to do auto rerun since rebuilding the project may take a long time.

@connor4312
Copy link
Member

connor4312 commented May 24, 2023

I've implemented proposed API for this:

declare module 'vscode' {

	export interface TestController {

		/**
		 * Marks an item's results as being outdated. This is commonly called when
		 * code or configuration changes and previous results should no longer
		 * be considered relevant. The same logic used to mark results as outdated
		 * may be used to drive {@link TestRunRequest.continuous continuous test runs}.
		 *
		 * If an item is passed to this method, test results for the item and all of
		 * its children will be marked as outdated. If no item is passed, then all
		 * test owned by the TestController will be marked as outdated.
		 *
		 * Any test runs started before the moment this method is called, including
		 * runs which may still be ongoing, will be marked as outdated and deprioritized
		 * in the editor's UI.
		 *
		 * @param item Item to mark as outdated. If undefined, all the controller's items are marked outdated.
		 */
		invalidateTestResults(item?: TestItem): void;
	}
}

I've gone back and forth on the method name a few times 🤷 Please let me know if there are any concerns with this. You can try it out in the next Insiders.

@matepek
Copy link
Author

matepek commented May 25, 2023

Hello,
Two things.

  1. For TestMate C++ in 99% of the cases it will have a set of items instead of just one item. API could be friendlier but I can use a for loop too.

  2. I'm not sure how will it work together with continuous run. As you said the "The same logic used to mark results as outdated may be used to drive continuous test runs." I assume it will be order sensitive so I should mark the tests outdated then trigger the continuous run otherwise I might invalidate fresh results. Is my assumption correct?

connor4312 added a commit that referenced this issue May 25, 2023
* testing: add proposed testInvalidateResults API

For #134970

* fix tests
@connor4312
Copy link
Member

For TestMate C++ in 99% of the cases it will have a set of items instead of just one item. API could be friendlier but I can use a for loop too.

Sure, I will have it take both an array as well as a single value.

I assume it will be order sensitive so I should mark the tests outdated then trigger the continuous run otherwise I might invalidate fresh results. Is my assumption correct?

Correct, if you have ideas to clarify wording let me know:

   * Any test runs started before the moment this method is called, including
   * runs which may still be ongoing, will be marked as outdated and deprioritized
   * in the editor's UI.

@connor4312 connor4312 added this to the July 2023 milestone Jun 27, 2023
@connor4312
Copy link
Member

Finalized in #188180

@connor4312 connor4312 added the verification-needed Verification of issue is requested label Jul 25, 2023
@alexr00
Copy link
Member

alexr00 commented Jul 26, 2023

@connor4312 what is the best way to verify this?

@alexr00 alexr00 added the verification-steps-needed Steps to verify are needed for verification label Jul 26, 2023
@connor4312
Copy link
Member

  1. Use the test provider sample https://github.com/microsoft/vscode-extension-samples/tree/main/test-provider-sample
  2. Call ctrl.invalidateTestResults(file) here https://github.com/microsoft/vscode-extension-samples/blob/main/test-provider-sample/src/extension.ts#L134
  3. F5, run all tests, and change a file. Validate that the node in the test explorer gets dimmed and no "proposed" errors are thrown when calling the API.

@andreamah andreamah removed the verification-steps-needed Steps to verify are needed for verification label Jul 26, 2023
@rzhao271 rzhao271 added the verified Verification succeeded label Jul 26, 2023
@rzhao271
Copy link
Contributor

Verified, though it was easier for me to see the change with a dark theme than a light theme.

@github-actions github-actions bot locked and limited conversation to collaborators Sep 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-finalization feature-request Request for new features or functionality testing Built-in testing support verification-needed Verification of issue is requested verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

6 participants