Expected Tree structure for dir / file / namespace / test?

[shahms]

I'm working on an adapter for bazel and encountering some awkwardness in mapping between Bazel's concept of a test and neotest's. Specifically there is a M:N relationship between Bazel test targets and files (as in: a single file may be part of multiple test targets and a single test target may exercise multiple files). Figuring out this relationship from Bazel is easy enough, but I'm struggling a bit in mapping this back to neotest. Specifically, how strict is the hierarchy of dir > file > namespace > test expected to be? I'd like to be able to "run" a test file, exercise the relevant test target(s) and report results despite those targets not really being within the file.

To some extent, the test target is itself a test (or namespace) which may contain files which may additionally contain namespaces or tests, but I'm not sure how well that structure would be supported.

Thanks!

[fredrikaverpil]

I'm the author of neotest-golang and I've implemented dir/file/namespace/test where I've chosen to utilize namespaces for testify test suites only. But you can for example opt for only implementing support for file or test. You don't have to implement/support all of these strategies. Neotest has this kind of (undocumented?) fallback of sorts which fallsback onto the next strategy if you implement it right. I would recommend starting with the most useful/stable of these and get it to work end-to-end with command execution and output processing into Neotest result data. For me it was to start with the test strategy. So initially my adapter ran individual tests even if you opted to run dir or file, which was very slow (Go would build between every test) but it worked. Then I extended support so to also properly support the other strategies, which has now made neotest-golang a lot faster.

You should be able to look at my init.lua::build_spec to get a pretty good understanding of what the relationship between these strategies are like: https://github.com/fredrikaverpil/neotest-golang/blob/main/lua/neotest-golang/init.lua#L65-L128

I'm also leveraging go list to deal with something that sounds a little similar to your mapping issue. I need to figure out what it means that you want to run a file, as Go doesn't really care about files (you can't run a command like go test myfile.go). It instead cares about packages. So when a user runs tests in "a file", I have to go do some mapping and figure out the package (using go list) and also conjure a regexp which filters on the test names in that package which corresponds to the test functions of the given file. The end result is I produce a go test command which does indeed run all the tests in a given file, as would be expected by the user.

If something's unclear there, don't hesitate to give me a ping!

Also, I figured I'd just mention that there's a fairly new neotest bazel adapter here: https://github.com/sluongng/neotest-bazel
The author also posted this: #449

And I'm also looking to support custom test runners in neotest-golang which would open up for adding a bazel runner, although one would also have to process the bazel output as it differs from the go test output: fredrikaverpil/neotest-golang#189
However, I'm not a bazel user myself and given that you most often seem to have more than one language in the mix with bazel, it might not make a lot of sense to add a bazel runner to neotest-golang. It might be better to do that the other way around and have a bazel adapter which hooks into using neotest-golang code for e.g. detecting tests, as discussed here: sluongng/neotest-bazel#1
Once you have that, you can in your own bazel adapter create the bazel command you need and execute that - and process the bazel output into Neotest results.