Roadmap

[alfaix]

Roadmap to an actual working plugin:

• [x] Save file -> runner mapping to disk
• [x] Better support for choosing which executable to run: allow changing an executable
• [x] Tests
• [ ] Support TEST_P
• [ ] Warn if the compiled executable is stale (by checking mtime)
• [x] Support debugging
• [x] Add configuration (colors, edge-case choices, etc.)
• [x] Documentation

For p.2 ideally it should be a button in neotest test window that would allow to pick which tests to run with which executable. Should also provide an actual UI with paths and all to configure it (minui?)

Once that's done, consider possible solutions for the following edge cases:

1. Interleaving namespaces (currently leads to "run nearest" being wonky, no obvious solution without a gigantic refactoring of neotest itself)
2. A namespace spread across multiple files (currently treated as two different namespaces)

[llllvvuu]

Could also be cool to use cmake-tools.nvim to automatically populate the "executable" field.

Warn if the compiled executable is stale (by checking mtime)

On a similar note, could have the prompt be something like "Build with CMake? build / run without building / cancel"

1. Interleaving namespaces (currently leads to "run nearest" being wonky, no obvious solution without a gigantic refactoring of neotest itself)

Even with tests right next to each other, e.g.

TEST(A, B) { /* ... */ }
TEST(A, C) { /* ... */ }
TEST(D, E) { /* ... */ }

it acts wonky. Tricky problem though.

[alfaix]

I'll look into integrating with cmake-tools.

Another idea was to use marks in the summary window, since that's probably far more convenient than entering everything manually. Ideally I think it should be using build tool interface (cmake, bazel, makefiles even) and manual specification as a fallback.

[jla2000]

@alfaix Is TEST_F also no yet supported? Cannot seem to get it to detect the tests there

[alfaix]

@jla2000 TEST_F should be working, or at least is working in integration test (see tests/integration).

Could you please follow these steps:

1. Update neotest and neotest-gtest.
2. Go to neotest-gtest/tests/integration.
3. Build the test executable (see Makefile).
4. Run the tests like you usually do via notest.

If integration tests work for you, please try to create a minimal reproducible example of tests that don't work and put it in a separate issue. Otherwise, please create an issue, including your neovim version and describing precisely what happens when you run tests.

[jla2000]

@alfaix Sure thing, I will try these steps out once I'm back on the project and create an issue otherwise :)

Also about this integration with cmake-tools.nvim, there is already this small plugin here https://github.com/hfn92/cmake-gtest.nvim that could be useful when trying to implement this feature

[jla2000]

@alfaix It does actually work now for me, but it took a bit of time. I tried running lua require("neotest").run.run() a few times until i got finally a prompt to specify the executable. In between I got the message "no tests found" from neotest. I guess some indexing is performed in the background. For me it is not really usable yet tho, as I would need to specify also the inherited working directory for the test executable. This would be another property that could be inherited from cmake-tools as it can be configured there.

Edit: It might be now working since I added "CMakeLists.txt" as entry for detecting root path. Should this maybe be included as default?

[alfaix]

Hey @jla2000, the "no tests found" thing is probably because root was not found. I think it's reasonable to put a warning if a test file (like test_something.cpp) is found, but root directory is not - I'll put it on my todo list :)

Regarding CMakeLists.txt: I don't think it's a good default. It is usually not only present in the root directory, but also in nested directories. This will lead to each sub-directory maintaining a separate adapter, which will lead to all kinds of annoyances. Unlike Bazel's BUILD/WORKSPACE, CMake does not have a file that is only in root directory, at least as far as I know.

I think .git alone covers 90% of use cases, but if CMakeLists.txt works for you personally - you can always provide your own root function via config.

[galou]

I'm working with ROS2 in a workspace with multiple repository and a single build directory (where the generated test executables are). How do I setup which executable must be launched for a specific source file? As far as I understand, all the configuration is done in the Lua's variables dap.adapters and dap.configurations but how do I then set a different configuration for my source file (I don't want the configuration to be in my vim config directory but in the workspace)?

Thanks a lot!

[alfaix]

Hey @galou, I pushed some big changes and updated README.md with usage. Please let me know if that makes it clear. I'm closing this issue as the plugin is more-or-less full-featured now, and I'll keep track of further improvements in separate issues.