Test results integration using dap

[kimlai]

Hello,

I've been toying with integrated test results when running them using the dap integration:

Screen.Recording.2023-04-27.at.19.35.28.mov

The fact that the test explorer knows everything about test suites makes this much more robust and easy to code than parsing the test names in opened buffers (which is what I did before). I guess I could use a custom handler and duplicate what is done in test_explorer.lua, but it seems a bit wasteful and not very resilient to metal updates. For my experiment I just added this line:

metals_get_tests = function()
  return state
end

Would you be interested in modifying the test explorer code to make this kind of thing possible?

[ckipp01]

Hey! This is really neat! Thanks for sharing! I'm totally open to edit the current test explorer to make something like this work. Ideally it would allow for whatever type of extensability someone wants while also retaining the existing core functionality. So yea, whether that adding a new function or slightly changing some of the existing ones (as long as what is currently being done can still work), then yea I'm fine. Feel free to shoot in a draft PR or something with some ideas.

[kimlai]

ok great, I'll try to implement the last feature that I want (displaying a ? next test cases when they have been discovered but not yet run) which will probably involve a way to pass a callback to nvim-metals to execute my code when a test is added to the test explorer state. Once I have that I'll open a PR.

[ckipp01]

displaying a ? next test cases when they have been discovered but not yet run

If you're not using the test explorer and instead relying on code-lenses, you already get this though right? What would the benefit of this be over that?

[kimlai]

Four reasons (not saying any of them is good though, happy to be convinced that I don't need to write more code 😄) :

• the test explorer code is not executed when lenses are on, so I don't get all test test metadata. I guess we could overcome that easily though, I was just trying to limit modifications to nvim-metals as much as possible to get things working.
• I don't really like to have a lens saying test | debug test when they're actually there exact same thing (if my understanding of how metals handles it is correct).
• when I tested this with code lenses (by parsing the test output), the lens virtual text would disappear and reappear after it has run, and the test result mark would sometimes be displayed before the lens text and sometimes after. I didn't investigate though so maybe it is possible to make the display order deterministic.
• I plan on trying to write a telescope adapter for the test explorer, because fuzzy-finding tests by name in a codebase sounds like something I would like to have, and in this case I'll be using the test explorer, not lenses.

[ckipp01]

I don't really like to have a lens saying test | debug test when they're actually there exact same thing (if my understanding of how metals handles it is correct).

I don't believe they are. For example just running the test lens won't actually stop at any breakpoints whereas the debug test one will.

I plan on trying to write a telescope adapter for the test explorer, because fuzzy-finding tests by name in a codebase sounds like something I would like to have, and in this case I'll be using the test explorer, not lenses.

Ah yea this one makes a lot of sense.

[kimlai]

I don't believe they are. For example just running the test lens won't actually stop at any breakpoints whereas the debug test one will.

Yes you're right, I was getting mixed up with the fact that running main class and running tests both use the same metal-run-session-start command. I clearly saw the behaviour you're describing when I tried to reproduce #554 in VSCode.