[mini.test] interaction with vim.ui.select

[bennorichters]

Contributing guidelines

• I have read CODE_OF_CONDUCT.md

Module(s)

mini.test

Question

Is it possible to test user interaction with vim.ui.select? In this example, the test hangs.

child.lua("vim.ui.select({'a', 'b'}, {}, function(c) end)")
child.type_keys("<CR>")

The documentation about a hanging process says:

Common causes are active hit-enter-prompt (solution: increase prompt height to a bigger value)

Is that relevant here? And if so, how can that be achieved?

[echasnovski]

The documentation about a hanging process says:

Common causes are active hit-enter-prompt (solution: increase prompt height to a bigger value)

Is that relevant here? And if so, how can that be achieved?

Not hit-enter-prompt but it is indeed blocked and waits for user input. You can see how it looks by executing :lua vim.ui.select({'a', 'b'}, {}, function(c) _G.info = c end) inside nvim --clean: it "blocks" Neovim and waits for user to type a number followed by <CR>. To test exactly that, this advice works here:

child.lua_notify("vim.ui.select({'a', 'b'}, {}, function(item, idx) _G.info = { item, idx } end)")
child.type_keys('1<CR>')
eq(child.lua_get('_G.info'), { 'a', 1 })

However, the vim.ui.select is meant to be overridable, so I find it better to override it inside child process for easier testing. Here is an example from 'mini.snippets' tests. And here is how to use it: mock vim.ui.select which will select particular choice and then execute code which will use vim.ui.select. No lua_notify needed and you can test that vim.ui.select was called with the arguments you expect.

[bennorichters]

Thank you for your fast and clear answer!