Start discovering all available tests lazily

[vinistock]

Motivation

This is the first step in addressing several test explorer related issues that we currently have open.

This PR implements lazy test discovery up until the file level.

Implementation

The VS Code API for the explorer supports lazily discovering tests by implementing the resolveHandler. I essentially only implement two resolutions:

1. If there's only one workspace folder, we eager discover all test files in the workspace
2. If there are many workspace folders, then the first level in the hierarchy are the workspaces themselves. If you open any of them, then it triggers resolution and we discover all available tests in that workspace

The tests are discovered using the VS Code findFiles API, which is very efficient and will avoid having us implement an indexing-like mechanism in the server. Since the test explorer is VS Code only anyway, this should be fine.

I also considered two levels of hierarchy for tests (in addition to the workspace when there are many). The firsts level is the test/spec/features directory. Since there may be many of them in an application split by components, we need to have that level of grouping.

The second level is the immediate subdirectory of the test/spec/features directory, which in a Rails app normally accounts for models, controllers and so on. This hierarchy is useful because it will allow users to take actions like running all tests in a workspace, test directory or all tests of a kind (e.g.: models).

Notes

This PR doesn't yet implement the resolution of the test files themselves. The approach we will take for that is asking the server for which tests are available in a file, which gives us the opportunity to include add-on listeners in the discovery.

Since the implementation is still partial, I put a new under development feature flag.

Automated Tests

Added tests.

Manual tests

Enable this under development flag

{
  "rubyLsp.featureFlags": {
    "newTestExperience": true
  }
}

Then start the extension on this branch and navigate tests

demo.mov

[vinistock]

• Start discovering all available tests lazily #3120 👈 (View in Graphite)
• Allow for under development feature flags #3119
• main

---

How to use the Graphite Merge Queue

Add the label graphite-merge to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[st0012]

Is it possible to expand test/controllers/foo_controller_test.rb in the test explorer when I opened foo_controller_test.rb in the editor? Similar to how VS Code would expand the file explorer based on the currently opened file.
Not a blocker for the PR but it'd be a very useful feature IMO.

[vinistock]

Is it possible to expand test/controllers/foo_controller_test.rb in the test explorer when I opened foo_controller_test.rb in the editor?

Yes! Added that. Note that you need to have clicked on the explorer first, to lazily populate the tests. We don't force the explorer to reveal, but if you're already there, we focus on the current test.

[st0012]

Tested it in Core, IRB, RDoc, and ruby-lsp-rspec. All worked as expected 👍

One non-blocking suggestion, I think the experience would be better if it can automatically expand results to the first level having multiple results.

For example, in IRB I needed to expand test and then irb even though both of them are the only item on their level.

[vinistock]

Merge activity

• Feb 7, 4:55 PM EST: The merge label 'graphite-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Feb 7, 5:24 PM EST: A user merged this pull request with the Graphite merge queue.