Capture and interpolate dynamic tests

[adrigzr]

I want to implement in neotest-jest the possibility to capture and interpolate dynamic tests as:

test.each([1, 2, 3])("case %u", () => {
  // implementation
});

This code should generate the following tests:

• "case 1"
• "case 2"
• "case 3"

For this to work, I've created a query like:

((call_expression
  function: (call_expression
    function: (member_expression
      object: (identifier) @func_name (#any-of? @func_name "it" "test")
    )
    arguments: (arguments (_) @test.args)
  )
  arguments: (arguments (string (string_fragment) @test.name) (arrow_function))
)) @test.definition

where @test.args are the arguments passed to the each method.

For this to work, I need to do some changes in neotest:

diff --git a/lua/neotest/lib/treesitter/init.lua b/lua/neotest/lib/treesitter/init.lua
index 26b7e8c..8b44f6a 100644
--- a/lua/neotest/lib/treesitter/init.lua
+++ b/lua/neotest/lib/treesitter/init.lua
@@ -40,11 +40,13 @@ local function collect(file_path, query, source, root)
       ---@type string
       local name = vim.treesitter.get_node_text(match[query.captures[type .. ".name"]], source)
       local definition = match[query.captures[type .. ".definition"]]
+      local args = match[query.captures[type .. ".args"]]

       nodes:push({
         type = type,
         path = file_path,
         name = name,
+        args = args and vim.treesitter.get_node_text(args, source) or nil,
         range = { definition:range() },
       })
     end

But even with this, I need a method to generate more tests based on this args in neotest.

Is this the best way or do you have something in mind for these cases?

[rcarriga]

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.

[rcarriga]

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.

[rcarriga]

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