[mini.test] testing async functions

[maxandron]

Hi,

I recently started tinkering with writing plugins, and even more recently started using mini.test
Currently, I'm writing an adapter for neotest which uses nio.

I wonder what is the best approach for testing async functions with mini.test (in a child process)?

One option I see is to make the async function print the result and then capture it with cmd_capture, but that feels very backwards.
Another option is to sleep, which also seems backward.
Should I poll a variable?

I'm probably missing an obvious solution due to my unfamiliarity.

I would love your advice on the best approach.
Thank you!

[echasnovski]

This very much depends on the tested function.

If the problem here is to test a function which executes not immediately and can take unknown beforehand amount of time to finish, then the most straightforward approach is to wait some amount of time before checking the state of the child process. This is how I usually go with it. Here is an example from 'mini.test' test. Choosing an actual time to wait is tricky: should be long enough to have small number of false negatives but not long enough to unnecessarily prolong test execution.

The other situation is if async function is meant to do something in a known amount of time (like show completion in 300 ms). Then the approach is similar but I also like to test if there is no side effect just before time expires. There are many examples in 'mini.nvim' tests, here is the first that came to mind.

Hope it helps. If there any other questions, feel free to ask.

[maxandron]

Thank you for such a quick and thorough reply!
I feel like my case is actually simpler - I'm just using a function from nio for reading a file from disk. So it should finish quickly.
If I call it directly I get the error: Cannot call async function from non-async context which happens from nio when doing fs_open.

Sleeping solves the issue - but I risk creating a non-deterministic test.

This is how the test currently looks:

T["is_test_file()"]["contains cfg(test)"] = function()
  child.b.path = vim.fn.getcwd() .. "/tests/files/projroot/tests/example.cairo"
  child.lua([[require('nio').run(function()
    vim.b.result = M.is_test_file(vim.b.path)
  end)]])
  vim.uv.sleep(1)
  local result = child.lua_get("vim.b.result")
  eq(result, true)
end

P.S.

In the examples you linked - what does poke_eventloop (child.api.nvim_eval('1')) achieve? I'm guessing nvim_eval is pushed to the end of the event pool so we can be sure the rest of the scheduled tasks were completed?

[echasnovski]

Sleeping solves the issue - but I risk creating a non-deterministic test.

True. But sleeping a bit longer makes it close to being deterministic in most practical scenarios. If you can somehow track that async function is done executing (like it triggers a User event or something else), you of course can use it for a more reliable test. Sleeping a bit is just a simpler way to do that.

In the examples you linked - what does poke_eventloop (child.api.nvim_eval('1')) achieve? I'm guessing nvim_eval is pushed to the end of the event pool so we can be sure the rest of the scheduled tasks were completed?

I've got it from Neovimi tests and can't with 100% certainty say what it does. But yes, it is something like "ensure that all scheduled tasks are completed" type of thing. I remember it mattered only couple of times (the others I just used it after sleeping, so can't definitively tell), but still.

---

  local result = child.lua_get("vim.b.result")
  eq(result, true)

You can directly use child.b "redirection table" here: eq(child.b.result, true). See this for more examples.

[maxandron]

Thank you! I didn't realize the redirection table works both ways