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

Profile/metadata feedback on testing #218102

Open
connor4312 opened this issue Jun 25, 2024 · 1 comment
Open

Profile/metadata feedback on testing #218102

connor4312 opened this issue Jun 25, 2024 · 1 comment
Assignees

Comments

@connor4312
Copy link
Member

          In Dart, we were already handling debug session ends and calling `.end()` on the test run (whether it was created by VS Code, or by us). We don't seem to have any bugs with stopping debug sessions that are test runs.

However, restart doesn't work great - because it seems to end the test run, then start a new debug session that is not tied to a test run (so you don't get the results recorded). It's not clear to me if your fix here will solve that, but I wonder if there are going to have issues with test runs where VS Code doesn't have all of the related data. We discussed this before in #144169 (comment) about "Test: Rerun Last Run" not working because of this. If we let VS Code handle restarting test runs by just calling runTests, I think any context that we weren't able to capture in the TestRun won't come back to us, and we'll start a test run with some parameters missing.

Originally posted by @DanTup in #214486 (comment)

@connor4312
Copy link
Member Author

connor4312 commented Jun 25, 2024

I realized I never followed up on #144169 (comment), apologies.

but it didn't seem like they could be scoped to specific files, and the UX wasn't as good

The filtering is possible through use of the TestRunProfile.tag which, if set, says the profile is only applicable to tests with the given tag.

(eg. having a menu option for "execute using profile" and then having another step to pick one was just way more clicks):

Yea, currently users can pick the default profile used when they hit the button, but a non-default option will involve extra steps. However I did make a change in more recent versions such that the "run" button always works regardless of whether the default profile is applicable or not (we'll fall back to whatever profile does match it.) Not sure if that solves your use case, but I'd like to try and make profiles work for you.

Maybe we finally do need to add code lenses 😛 #133338

Update-goldens (run the tests, but instead of comparing the app screens to golden image files on disk, re-generate those images - for example because you've just made changes you know affect the UI)

Related, you may be interested in the testing/message/content menu contribution point which allows you to place a button on the failure message editor

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants
@connor4312 and others