[mini.test] add generic version of screenshot functionality

[MagicDuck]

Contributing guidelines

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

Module(s)

mini.test

Description

essentially, the issue I've run into is that sometimes a buffer contains more lines of text than is visible in the screenshot, but you would like to test them all the same. In such a case it be nice if there was a generic version of expect.reference_screenshot(), maybe let's call it expect.reference_snapshot(obj) and the snapshot file would contain the output of vim.inspect(obj).

This is an example dirty workaround that I have adapted for my tests: https://github.com/MagicDuck/grug-far.nvim/blob/393fb7379ee4bfcf67d717640763fd629363485f/lua/grug-far/test/screenshot.lua#L45 which results in screenshots like: https://github.com/MagicDuck/grug-far.nvim/blob/main/tests/screenshots/tests-test_search.lua---can-search-for-some-string-002

Not the prettiest cause of the empty attr lines, but it works for now 😄 .

[echasnovski]

Thanks for the suggestion!

My first instinct is that screenshot tests should be used specifically if there is no way of writing test without them. Like for testing highlihgting, extmarks, command completion, UI, etc. Or if it would bring huge inconvenience (like too much text to put into file), but this is arguable.

I do understand that having some "compare to reference" functionality might be useful. Like indeed something along the lines of expect.reference_object(obj) which saves vim.inspect(obj) on first run and then compares to the new vim.inspect(obj). But currently I am on the fence about it. I'll think about it.

[MagicDuck]

Thanks @echasnovski ! I've been really happy with mini.test so far apart from some minor inconveniences that I've reported, mostly due to the special nature of my plugin.

I don't know if you maintain a list of "plugins using mini.test" anywhere for glory / inspiration but if you do, feel free to add https://github.com/MagicDuck/grug-far.nvim to that list 😄

Also, side note, a bit of functionality that's been sort of tricky to figure out and was really critical in my situation was a childWaitForCondition function that polls for a condition to be true with a timeout (vim.wait() did not block for me). It's very tiny so up to you, but we might want to add something like this to the core, if you feel it's appropriate: https://github.com/MagicDuck/grug-far.nvim/blob/f0089e5c6ce0b20995b408c8fe9d6c9d8e5fd51c/lua/grug-far/test/helpers.lua#L83C10-L83C33

[echasnovski]

I don't know if you maintain a list of "plugins using mini.test" anywhere for glory / inspiration but if you do, feel free to add https://github.com/MagicDuck/grug-far.nvim to that list 😄

That's a good idea. I'll have this in mind. Thanks!

vim.wait() did not block for me

Not sure why though. It works as expected for me.

[MagicDuck]

vim.wait() did not block for me

Not sure why though. It works as expected for me.

Probably cause you were using it without a neovim child? With a child, it only works for me if I do it inside the child, like:

child.lua([[vim.wait(...)]])

which is ok, but not always convenient

[echasnovski]

Probably cause you were using it without a neovim child? With a child, it only works for me if I do it inside the child, like:

child.lua([[vim.wait(...)]])

vim.wait() inside test runner process with callback using child process. Like this.

[MagicDuck]

Would that not be waiting for any change in general though? In my case I was waiting for a specific change (for the buffer virtual text to contain some string). Anyways, it’s working the way I have it which is all that matters atm. Thank you!