Enhance Test Explorer

[ShuiRuTian]

rust-analyzer version: 0.3.1877-standalone (574e23e 2024-03-09)

I tried current implementation and found many flaws

• always display crates, even there is no tests
  
• display integration test like a crate fixed in Distinguish integration tests from crates in test explorer #16847
  
• not lazily, which means, it always returns all test cases in the crate when you made changes in any file.
• No output from rustc, this might make user feel something is frozen. I mean something like: fixed in Show compilation progress in test explorer #16845
  

It might not be very easy to fix these things, especially the third point(lazily)

Since we have test explorer anyway now, this channel might be another place to argue about whether we should implement test explorer main part in front-end(the editor) or backend(RA itself).

The client implementation is here: #14589

[HKalbasi]

@ShuiRuTian Thanks for opening this. It would be great if you can explain if your implementation has similar flaws, and if not, how it solves the problems. Here is the problems I see related to each item:

always display crates, even there is no tests

Detecting whether the crate contains any test requires parsing all of files of it, which is against the laziness. How did your implementation handle initial resolve request without showing the empty crates?

display integration test like a crate

Here, I didn't find out how to distinguish between integration tests and normal crates in a crate graph.

not lazily, which means, it always returns all test cases in the crate when you made changes in any file.

There is no problem in the way of this issue, I just kept the implementation simple by doing it at crate level granularity. We can easily change this to module level or file level.

No output from rustc, this might make user feel something is frozen. I mean something like

Is there any vscode api to report the progress in this way?

Again, thanks for all of your work related to the test explorer in r-a!

[ShuiRuTian]

It would be great if you can explain if your implementation has similar flaws, and if not, how it solves the problems.

Yeah, no. But it is kind of complex to explain the details, I build and maintain a small AST-like tree, most of issues would be how to update this tree.

Detecting whether the crate contains any test requires parsing all of files of it, which is against the laziness. How did your implementation handle initial resolve request without showing the empty crates?

Indeed, for the first time initialization, we have no choice if there is no test cases(but we might return quickly if there is any tests). We could only do better after initialization.

Here, I didn't find out how to distinguish between integration tests and normal crates in a crate graph.

Although kind of tricky, Runnable could tell us this info through cargoArgs. You could judge it through whether it includes "--lib", "--tets", "--bin". I did not found how this property is filled exactly, it should be got from "Cargo.toml"(and default value).

Is there any vscode api to report the progress in this way?

There is and there are many ways. It's flexible if you do the work on client side. But you are doing work on backend, so maybe create a vscode.Task to run build firstly? Is this feasible? Not sure...

[dfireBird]

While trying to enable the test explorer, I see nothing happened, then realized I should reload the window. So it would be nice, if we could prompt the user to reload the window, when we enable that setting?

I didn't wanna create a new issue for this, so I'm hijacking this one.

[lucas-labs]

Another issue I'm experiencing is that the test explorer is not running tests under a #[cfg(feature = "...")].

I think it should take the already existing rust-analyzer.cargo.features config into consideration?