Capture and interpolate dynamic tests about neotest HOT 3 CLOSED

OK I've gotten around to this. Instead of allowing for another capture type, I've gone with a more blind approach of allowing a build_position option to be given to the parse function. You can see the default for usage but it can return either a position or a list of positions so you can return sub-tests.

This approach should allow using treesitter captures to do some of the heavy lifting when parsing arguments.

from neotest.

The issue of parameterised tests has been raised by several adapters (#64 for example). I see a few ways to approach them

1. As described, try parsing the parameters and figuring out the parameters that way. This is probably the simplest method but also quite unreliable as it relies on parameters being in a form that is parseable.
2. Using a different parsing method such as LSP to basically do the same as 1 but (maybe) more reliably. This introduces the complexity of interacting with LSPs.
3. The adapter hooks into the test runner to get the tests. This is the most reliable method since it doesn't do any guessing, but it requires more from an adapter implementation. neotest-python for instance does hook into the runner for results and would be able to for discovery too, I just haven't implemented that. Jest in particular should be possible as they have https://github.com/jest-community/jest-editor-support/.
4. Returning a new tree from the results. This would allow runners to return newly discovered tests with results but I'm not sure how neotest core would manage regularly parsed tests and results discovered tests (e.g. when a file is written currently the entire tree is rebuilt, but that would lose the tests discovered from the results)

Option 3 is and always will be the best route to go, and I explicitly designed the interfaces with that route in mind, both neotest-python and neotest-plenary hook into the runner. I can add in a hook to generate tests from the args as you suggest though.

from neotest.

Going to close this as I don't believe neotest core can do much more, the rest will be down to adapters. Going with my fourth option above would be a large endeavour for a relatively minor feature, especially when there are better solutions

from neotest.