Still working on my neovim configuration.

I use Google test to write my unit tests. Which means that all the unit test begin with TEST(<groupName>, <testName>). This little script see if the cursor is inside a test sets a break point and then runs the test application for that test.

This is useful as I can run my make test from inside neovim that builds and runs the test. If any of the unit tests fail then the error is in the QuickFix list which allows me to jump to the failing test in a couple of key strokes and I can now invoke the test directly.

Any pointers on Bad Lua or bad usage of neovim functions and better ways appreciated.

  -- Set the Key <leader>du to run this command
  -- Run all the unit tests
  vim.cmd.DapRunUnitTests = function() vim.cmd.DapRunUnitTestCode({})     end

  -- Set the Key <leader>dt to run this command
  -- Run the unit test that the cursor is over.
  vim.cmd.DapRunOneTests  = function()
      -- Search backwards for a line that marks the begining of the TEST.
      local lineNo = vim.fn.search('TEST(', 'bn')
      if (lineNo == 0) then

      -- Extract the name of the test
      local text = vim.fn.getline(lineNo)
      local res = { string.match(text, "(%w+)%((%w+), (%w+)%)") }

      if (#res == 3 and res[1] == 'TEST') then
          -- Set a breakpoint at the current line
          -- Then run the unit test code specifying the unit test to run.
          vim.cmd.DapRunUnitTestCode({'---gtest_filter=' .. res[2] .. '.' .. res[3]})

  -- Function that runs the unit tests.
  vim.cmd.DapRunUnitTestCode = function(args)

      -- Use make to get runtime environment need to run the
      -- unit test application.
      local handle = assert(io.popen('make neovimruntime', 'r'))
      local output = handle:read('*a')

      -- Set the runtime environment.
      -- Need to modify for non MAC environments.
      require('posix').setenv('DYLD_LIBRARY_PATH', output)

      -- Set up the config needed.
      local config = {
          name = 'Launch',
          type = 'lldb',
          request = 'launch',
          program = 'test/coverage/unittest.prog',
          cwd = '${workspaceFolder}',
          stopOnEntry = false,
          args = args,

      -- Start the debug seasion.

1 Answer 1


auto shortcuts

  -- Set the Key <leader>du to run this command

There's a couple of comments in this standard format.

Hopefully a Makefile or other script reads them to generate .vimrc map_mode config lines.

Consider putting valid .vimrc syntax in these comments, so a trivial awk one-liner can generate a config file.


I guess you found
DapRunUnitTests a more convenient spelling than
DapRunUnitTestCode? Ok. Not sure why it's a win, given that it's bound to a keyboard shortcut. Whatever.

Or maybe you needed a line of source just to help with autogenerating a .vimrc?


  vim.cmd.DapRunOneTests  = function()
      if (lineNo == 0) then

Maybe beep? Or display some brief error indication? Then the user will know that this ran, there's no config mixup, the trouble stems instead from the buffer content.


  local res = { string.match(text, "(%w+)%((%w+), (%w+)%)") }

Rather than testing res[1], putting the literal in the regex would be simpler and more intuitive:

                               ... "TEST%((%w+), (%w+)%)") }

Also, I'm sure your whitespace is always immaculate. But when I am authoring code, sometimes the spacing is a bit sloppy until a prettyprinter cleans it up. You might prefer to accept greater variation in whitespace:

                               ... "TEST%((%w+),%s*(%w+)%)") }

Your subsequent use of res[2] and res[3] is a little more obscure than necessary. Consider assigning them to temp variables that have meaningful names.

nit, comment typos: "needed to run" and "non Mac environments".

I'm afraid that when I see "MAC" I think of comms layer 2 and IEEE-assigned 48-bit identifiers.

common path support

      require('posix').setenv('DYLD_LIBRARY_PATH', output)

Definitely this works for you. And you're running the test code as a child of vim, good.

Me? I tend to run within several environments:

  • editor
  • IDE
  • bash

The DapRunUnitTestCode function seems pretty generic across all those. So I'm sad that this logic is not e.g. packaged up in a bash script which vim calls. Alternatively, maybe this function would like to write a dot file which bash can conveniently source?

  • \$\begingroup\$ Hopefully a Makefile or other script reads them to generate .vimrc map_mode config lines. I am trying to write everything in lua to match what I see other people doing in neovim. I have translated all my .vimrc into lua scripts etc. Is that not the prefered new trick? \$\endgroup\$ Commented Jun 13 at 19:29
  • \$\begingroup\$ Maybe beep? Or display some brief error indication? Yes. That's a good idea. How? \$\endgroup\$ Commented Jun 13 at 19:30
  • \$\begingroup\$ Me? I tend to run within several environments: Me to. :-) Though not IDE (as vim is my IDE and editor) :-). It works in bash already natively as everything is connected via the Makefile to do everything correctly. Just trying to get my vim (neovim) and make file environment to interact nicely here. \$\endgroup\$ Commented Jun 13 at 19:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.