Skip to content

Run test using code lens does not open Test Results view #4951

Closed
Closed
Run test using code lens does not open Test Results view#4951
Labels
in testingRelates to test execution of Dart/Flutter tests for end usersis enhancementAn enhancement or improvement that should be listed in release notes but is not a bug fix.
Milestone
v3.88.0

Description

@jibbers42
jibbers42
opened on Jan 19, 2024

I'm guessing this is the correct repo as my issue in vscode repo was closed (microsoft/vscode#202895).

Describe the bug
A clear and concise description of what the bug is.
When using the "Run" code lens button, I'd like vscode to open the Test Results view. It sometimes opens the Debug Console and other times the only noticeable UI change is a badge number indicator showing on the Test Explorer icon. If I use the green button to the left in the "well" (I think that's what the area is called), then it does switch to the Test Results view.

If I change "testing.openTesting" to "openExplorerOnTestStart", then the code lens Run button only shows the badge indicator while the test is running (or maybe it sometimes will show Debug Console inconsistently as above, but I didn't see that). The green test button in the well does open the Text Explorer as configured.

To Reproduce
Steps to reproduce the behavior:

  1. Go to a dart test
  2. Click on the "Run" code lens button

Expected behavior
Open Test Results view

Screenshots
298182581-a4acfa57-a4ce-4a1c-a3c1-ac25cb69be20

Please complete the following information:

You can run the Dart: Collect Diagnostic Information command from the VS Code command palette (F1) to easily capture this information or provide it manually.

  • Operating System and version: "Windows 10 Pro" 10.0 (Build 22631)
  • VS Code version: win 1.85.2
  • Dart extension version: 3.80.0
  • Dart/Flutter SDK version: 3.2.2/3.16.2
  • Target device (if the issue relates to Flutter debugging):

Activity

  1. jibbers42
    added
    is bug
    on Jan 19, 2024
  2. DanTup
    added
    is enhancementAn enhancement or improvement that should be listed in release notes but is not a bug fix.
    in testingRelates to test execution of Dart/Flutter tests for end users
    and removed
    is bug
    on Jan 22, 2024
  3. DanTup
    added this to the v3.82.0 milestone on Jan 22, 2024

  4. DanTup commented on Jan 22, 2024

    @DanTup
    DanTup
    on Jan 22, 2024
    Member

    @connor4312 when you click the CodeLens links here, we call vscode.TestController.createTestRun() so I would have expected it to handle this.

    I'm going to try to fix this up by reading the value of openExplorerOnTestStart, but this feels a bit hacky (because if that setting changes, I need to keep in-sync). It would be nice if this could be handled automatically.

    I found the code that handles this at https://github.com/microsoft/vscode/blob/236d5dc072622d511e2f8f6ddd83fd24a7165467/src/vs/workbench/contrib/testing/browser/testingProgressUiService.ts#L43 but I don't know why createTestRun wouldn't trigger this code (I'm not familiar with this code).

  5. DanTup commented on Jan 22, 2024

    @DanTup
    DanTup
    on Jan 22, 2024
    Member

    @connor4312 actually, I'm a bit confused about this setting...

    The issue above mentions OpenExplorerOnTestStart but that seems to be about opening the Test Explorer, but the bug here is with the Test Results. It seems there's also an option for openOnTestStart (the default), however it's not clear to me what openOnTestStart means for the explorer (or what OpenExplorerOnTestStart` means for the test results). Is it possible to expand the descriptions on these enum values?

  6. DanTup
    added a commit that references this issue on Jan 22, 2024

    Move ability to get resolved config to config class

    864b030

  7. jibbers42 commented on Jan 22, 2024

    @jibbers42
    jibbers42
    on Jan 22, 2024
    Author

    @DanTup Looking back, I'm not sure why I mentioned openExplorerOnTestStart - I guess I was just showing the setting that controlled this and that the Run button didn't seem to respect the setting. Worse, I failed to mention that openOnTestStart was the setting I was actually interested in.

    @connor4312 can provide a more authoritative answer, but the comments on the settings seem to state that openOnTestStart should open the Test Results view...

      // Controls when the testing view should open.
  //  - neverOpen: Never automatically open the testing views
  //  - openOnTestStart: Open the test results view when tests start
  //  - openOnTestFailure: Open the test result view on any test failure
  //  - openExplorerOnTestStart: Open the test explorer when tests start
  "testing.openTesting": "openOnTestStart",

    image

    --

    Before I had mentioned that the Debug Console view sometimes shows inconsistently. To get the screenshot above, I used the green button in the well. It initially showed the Test Results view as configured, but then switched to the Debug Console. When I pressed it again, it switched to the Test Results view and stayed there.

    I'm unclear as to why this behavior changes or even who's responsible for it, but it may simply be something that only happens on first run - I just thought I should mention it.

  8. DanTup commented on Jan 24, 2024

    @DanTup
    DanTup
    on Jan 24, 2024
    Member

    Before I had mentioned that the Debug Console view sometimes shows inconsistently. To get the screenshot above, I used the green button in the well. It initially showed the Test Results view as configured, but then switched to the Debug Console. When I pressed it again, it switched to the Test Results view and stayed there.

    Yeah, I noticed when testing this that setting openOnTestStart will cause Test Results to be shown when the test run starts, but then Debug Console is shown automatically as a debug session starts afterwards. So unless you have them side-by-side, you'll probably always end up on the Debug Console. But if they are side-by-side, it still feels like openOnTestStart should apply to these programmatic invocations of tests and not require a language extension to re-implement whatever the logic is for that setting.

    I'm hoping @connor4312 agrees and this could be fixed in VS Code, but if there's a reason that can't be done, we should handle it here so it at least appears consistent.

  9. connor4312 commented on Jan 30, 2024

    @connor4312
    connor4312
    on Jan 30, 2024

    The reason the setting isn't used when started from the extension is that I don't want UI changes to be triggered by something the user didn't explicitly due. Before there was a proper "watch" mode (and even now that there is one) some extensions start test runs in the background / run tests continuously, and I don't want that leading to a bad experience for users.

    Is the only point where this is needed by Dart for code lenses? I had an issue for that for a couple years but closed it since there wasn't much community interest in it, but we could revive it...

  10. DanTup commented on Jan 30, 2024

    @DanTup
    DanTup
    on Jan 30, 2024
    Member

    Before there was a proper "watch" mode (and even now that there is one) some extensions start test runs in the background / run tests continuously, and I don't want that leading to a bad experience for users.

    Ah, that makes sense.

    Is the only point where this is needed by Dart for code lenses?

    There are some other places like the "Rerun Last Test Session" command (because the built-in command doesn't work for some cases - see discussion at microsoft/vscode#144169 (comment)), but I presume this also impacts pressing F5 to run the test file?

    Maybe we could pass a bool when we start a test run to indicate it was/was-not user-initiated, which you could use a signal to show things like Test Explorer/Test Results based on user settings? I guess in some ways this is similar to the contexts we get for things like Code Actions/Format (to know if we're running on-save versus user-invoked).

  11. DanTup
    modified the milestones: v3.82.0, v3.84.0 on Jan 30, 2024
  12. DanTup
    modified the milestones: v3.84.0, v3.86.0 on Feb 20, 2024

  13. DanTup commented on Mar 26, 2024

    @DanTup
    DanTup
    on Mar 26, 2024
    Member

    @connor4312 any thoughts on the above?

  14. DanTup
    modified the milestones: v3.86.0, v3.88.0 on Apr 2, 2024

  15. connor4312 commented on Apr 3, 2024

    @connor4312
    connor4312
    on Apr 3, 2024

    I've made an API proposal here: microsoft/vscode#209491

  16. DanTup commented on Apr 4, 2024

    @DanTup
    DanTup
    on Apr 4, 2024
    Member

    Thanks! :)

  17. DanTup
    added
    blocked on vs code / lsp / dapRequires a change in VS Code to progress
    on Apr 18, 2024
  18. DanTup
    modified the milestones: v3.88.0, v3.90.0 on Apr 18, 2024
  19. DanTup
    closed this as completedin b68b9c2on Apr 23, 2024
  20. DanTup
    removed
    blocked on vs code / lsp / dapRequires a change in VS Code to progress
    on Apr 23, 2024

  21. DanTup commented on Apr 23, 2024

    @DanTup
    DanTup
    on Apr 23, 2024
    Member

    I've committed a fix for this that will be included in the next Dart-Code release, but it also requires a VS Code update to apply (which usually ships a week or so into each month).

  22. DanTup
    modified the milestones: v3.90.0, v3.88.0 on Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    in testingRelates to test execution of Dart/Flutter tests for end usersis enhancementAn enhancement or improvement that should be listed in release notes but is not a bug fix.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions