Add C++ (GTest) or vim-gtest support

[tpotie]

Hi! Great plugin! :D

I have been working on getting a better integrated neovim setup, where coding, debugging & testing feel more at home with each other. Your plugin really takes care of integrating the testing procedure right back into vim. Very nice! It is able to provide the quick pass/fail of testing (TDD) that I am looking for (at least in vim - this I have been able to replicate with vscode for example).

As I am trying to migrate to vim completely, I am looking to find the test integration for C++. I have looked into vim-test to see if I could integrate C++ test support (using Google Test) but I came across a hiccup where it seems to be a bit tricky to identify the namespace and test names (as in GTest they are represented on one line as TEST_F(namespace/suite, test) {} - and that's if they fit on one line - due to possible width screen format limits set)(There is another hiccup in terms of launching the compilation on file changes - but I see this as being able to be passed to another shortcut or passed as a pre-hook to the test run command)

However, there is also https://github.com/alepez/vim-gtest, that handles running google test from within vim (similar to vim-test that it doesn't have the pass/fail and summary overview that vim-ultest provides).

This leads to:

Feature Request (or help)

A request to integrate C++ support (using GTest), is this possible by adding extra configs to vim-ultest? Or by adding support for vim-gtest?

This request also leads to, asking for your opinion on what could be possible in getting C++ test support into vim-ultest? As you know the code and have experience interacting with vim-test amongst other vim plugins - is there a possible area that you see could be the easiest to get this added? (As I am willing to provide help - in the form of coding or other - but I do not know the landscape as well as you)

[rcarriga]

Hmm yep I can see how that's a bit of a hiccup as you put it :sweat_smile: That definitely breaks a lot of assumptions in vim-test and vim-ultest. Are the namespaces exclusive to a single file or can multiple files share namespaces? I've had a brief look at googletest's documentation but I can't see a straight answer and I have no experience in C++.

[tpotie]

The namespaces are exclusive to a single file. There can, however, be multiple namespaces in the same file. The macros used are one or a combination of the following (but this would be taken care of by a regexp):

TEST(namespace/suite, test) {}
TEST_F(namespace/suite, test) {}
TEST_P(namespace/suite, test) {}

[rcarriga]

As an initial step I think it'd be fairly trivial to add the ability to run individual tests and files. You would just need to write a custom vim-test runner which are quite simple that would construct the test names correctly when creating command arguments. If you wish to go this route I'm happy to help!

Being able to show/run namespaces would require some larger changes to vim-ultest than I'd like to make. The reason for this is that vim-ultest has some factors of its design that place serious limits upon it (including being based on vim-test). There are several very useful features which I just can't implement in a nice way with the current design (see #70 #71 #73 #78 #92 #93) and now this.

For a proper solution to all of these issues I am in the middle of writing a new testing plugin that is much more robust and extensible, which will allow more fine tuning per language/runner along with many other features. I'll hopefully be opening this up for initial use and testing soon. I'll also be looking for help with individual languages that I don't use!

[tpotie]

Thanks for the info. Yes if you can provide some help, I would be interested in going down the path of writing a custom vim-test runner :) I have an idea on how I could possibly do it (possibly having a regexp for the test, that picks up the namespace + test at the same time to pass as args - while keep the namespace regexp empty). But I am interested on your opinion if there is a better way.

The tickets linked are interesting, that is quite a bit and would make this test environment even more tightly integrated - which would be very nice. For the result summary in vim-ultest - is it necessary to have an Output Parser? For it to show nicely (line by line, with red/green status) such as shown on the demo gifs in the README?

The new testing plugin sounds very interesting. If you are looking for help / testers, please let me know :)

[rcarriga]

I have an idea on how I could possibly do it (possibly having a regexp for the test, that picks up the namespace + test at the same time to pass as args - while keep the namespace regexp empty). But I am interested on your opinion if there is a better way.

That's exactly what I was thinking alright! It would be compatible with vim-ultest except if you had tests with the same name in different namespaces in the same file. An ID is generated based on the file and namespaces for each test but for this case the namespaces would not be detected. You could use a different pattern with g:ultest_custom_patterns which kept the namespace in the name but you'd end up with a weird looking name with a comma like Namespace, TestName. Not sure if this problem would affect you or not.

For the result summary in vim-ultest - is it necessary to have an Output Parser? For it to show nicely (line by line, with red/green status) such as shown on the demo gifs in the README?

Nope basic vim-test compatibility is enough to achieve this. The custom parsers though allow you to run all tests in one process as opposed to running each separately. This is relatively easy to add if the output is not too complicated and I'd be happy to help with a PR.

The new testing plugin sounds very interesting. If you are looking for help / testers, please let me know :)

Will do thank you :grin:

[tpotie]

Thanks for the info and the positive exchange :)

I ended up putting together a basic setup to get GTest running (it works with :TestNearest & :TestFile (which actually just runs all the tests)

It doesn't fit in with how vim-test parses the namespaces and tests though. I ended up needing to pass through the initial TEST/_F/_P so in turn it can either run the test directly or with an * (in the case of the parameterised tests of TEST_P)

But in any case, there it is :) maybe it could help someone else

(Comment here: https://github.com/vim-test/vim-test/issues/294#issuecomment-1046295236

Script: https://github.com/Electrobub/vim-test/blob/gtest-cpp-proof-of-concept/autoload/test/cpp/gtest.vim)

[krishnakumarg1984]

For a proper solution to all of these issues I am in the middle of writing a new testing plugin that is much more robust and extensible, which will allow more fine tuning per language/runner along with many other features. I'll hopefully be opening this up for initial use and testing soon. I'll also be looking for help with individual languages that I don't use!

This is seriously good news. Please let us know if we can help with some beta testing.

[rcarriga]

In case you hadn't seen it I've released the new plugin https://github.com/rcarriga/neotest. There's no GTest integration but if someone wanted to add support for it, I'd be happy to help out :smile: