request: improve the testing section by adding minimal, concrete steps

[mikavilpas]

I'm spending some time going through the suggestions in the testing section. I think the recommendation to move from plenary.test to busted sounds good, and it doesn't seem too complicated since it's apparently a superset of what my plugin is already using.

I also love the recommendation on using luarocks. I built my own hacky system that uses lazy.nvim to set up tests (it uses its own lazy-lock.json that I commit to the repository), but I will see if I can move to using luarocks instead.

I'm not sure what the status in the neovim plugin ecosystem is on using luarocks, so that's why I picked lazy.nvim because it can work with everything (including specific git branches, tags, commits etc).

---

I'm looking for clarification on a few things that might also be good candidates to add to the guide if you feel like it:

1. As a plugin author, https://mrcjkb.dev/posts/2023-06-06-luarocks-test.html seems like a short and "to the point" guide. Do you think it could be highlighted so that it's easier to see? Currently it is the second item.

2. The instruction to ...use [busted](https://github.com/lunarmodules/busted) for testing, which is a lot more powerful. is good, but it's a bit of reading 😅... I think it would be very effective to have a list of concrete actions on how busted should be set up:

   • as a beginner plugin author, what programs should I install to get started?

     • e.g. "Use the following commands to set up your development environment" (as few lines of text as needed):

       brew install luarocks
       luarocks config lua_interpreter 5.1
       ....

   • how should I structure my project's tests? This PlenaryBusted guide is very succinct and helpful in this regard.

3. Is nlua required? Do I need it, or can I just get started with neovim instead?

[mikavilpas]

Also related vhyrro/luarocks.nvim#12, if lua specifc instructions are deemed necessary, a workaround could be added to this issue (I don't know what one would be right now)

[mrcjkb]

Hey again 😄

I'm not sure what the status in the neovim plugin ecosystem is on using luarocks, so that's why I picked lazy.nvim because it can work with everything (including specific git branches, tags, commits etc).

Typically, if a plugin isn't on luarocks, I

• open a PR to get it on luarocks
• if the maintainers don't respond in a reasonable amount of time, I add it to NURR

Another option is to add a rockspec and use luarocks install <path-to-rockspec> to install it directly from the rockspec (in this case, it doesn't have to be on luarocks).

Do you think it could be highlighted so that it's easier to see? Currently it is the second item.

I think nlua will be the easiest tool to use for most people, so maybe an example project and some documentation on how to set up a GitHub Action in the nlua readme is the way to go.

I think it would be very effective to have a list of concrete actions on how busted should be set up

This, too, is probably better kept in the busted or nlua documentation.

how should I structure my project's tests?

I would rather see this in the busted docs. It's out of scope for this guide.

Is nlua required? Do I need it, or can I just get started with neovim instead?

Not strictly. It just makes it more convenient, because it translates Lua's CLI to Neovim's.

[mrcjkb]

Also related vhyrro/luarocks.nvim#12, if lua specifc instructions are deemed necessary, a workaround could be added to this issue (I don't know what one would be right now)

In principle, the lua version used with the luarocks installation shouldn't matter.
luajit and lua 5.1 are mostly compatible with one another.

[mrcjkb]

fe4546d

[mikavilpas]

For future reference, I finally did the conversion in my project. The change can be found here mikavilpas/yazi.nvim#113 (in case technical details might be useful for others)

Really happy with the results, by the way! 🙏🏻

• the test output is much clearer due to the use of colors
• I can now run only one test (previously I always ran multiple/all)
• the CI setup is much simpler
• also the local setup is much less hacky