[mini.test] MiniTest.new_child_neovim() add option to proxy to current neovim for debugging purposes

[MagicDuck]

Contributing guidelines

• [X] I have read CONTRIBUTING.md
• [X] I have read CODE_OF_CONDUCT.md

Module(s)

mini.test

Description

Sorry for all the issues I filed lately, but just ran into this problem the other day. Basically tests were hanging and I had a devil of a time figuring it out cause there was no way to know why it was happening. My only recourse was to strategically guess and comment out lines until I hit upon the problem. The problem was a function doing str:gsub('something', replacement) where replacement was nil.

My suggestion is to add an option to MiniTest.new_child_neovim() so that when it's true, it does not spawn a child instance, but proxies all the calls like child.lua(), child.type_keys(), child.get_screenshot() to the current nvim. This would allow one to run the test in nvim and see the error that pops up.

I am not sure if there already is a way to do that and I just missed it...

[echasnovski]

Thanks for the suggestion! Please don't hesitate creating an issue if you did your best searching the answer in doc/help/issues and did not find it.

Basically tests were hanging and I had a devil of a time figuring it out cause there was no way to know why it was happening.

It is a common issue I faced as well. Here is the usual culprits (second bullet point).

That said, I don't think this is a good idea because every test is meant to be run in a clean state. So automating it to be done in current Neovim process (test runner) will not lead to the same environment/conditions.

I feel that the best approach is indeed a combination of:

• Try to mitigate blocking with know "techniques".
• Make an educated guess in source code and remove it (or log persistently just before it).
• Try to replicate manually in the separate clean Neovim process (like nvim --clean -u scripts/minimal-init.lua and perform test steps manually).

Closing as not planned.

[MagicDuck]

That said, I don't think this is a good idea because every test is meant to be run in a clean state. So automating it to be done in current Neovim process (test runner) will not lead to the same environment/conditions.

Totally agree with that, the suggestion was just to have an option to turn on for emergency situations. I understand though if you prefer not to.

[MagicDuck]

Try to replicate manually in the separate clean Neovim process (like nvim --clean -u scripts/minimal-init.lua and perform test steps manually).

Just got back to it and I think this is a critical step, but I needed to make sure the plugin is set up with the same config as the tests. I made a little Makefile thing for myself that can easily replicate it now 😄 I feel like I am learning something everyday with testing neovim, haha.

In case anybody else reads this:

# launches test version of nvim that has the same plugin configuration as what the tests get
# this is useful sometiemes to check what is going on when child neovim processes just hang without any output
launch-test-nvim:
    nvim --noplugin -u ./scripts/test_plugin_config.lua -c GrugFar

where test_plugin_config.lua:

vim.cmd([[let &rtp.=','.getcwd()]])
vim.cmd('set rtp+=deps/mini.nvim')

Helpers = require('grug-far/test/helpers')
GrugFar = require('grug-far')
GrugFar.setup(Helpers.getSetupOptions())