Unit tests

[champignoom]

Issues

• I have checked existing issues and there are no existing ones with the same request.

Feature description

It appears that some fix (like ffabc4c) might cause new problems (like #831 #833). Some simple unit tests might help, for example using https://github.com/nvim-lua/plenary.nvim#plenarytest_harness.

Help

Yes

Implementation help

No response

[champignoom]

for example using https://github.com/nvim-lua/plenary.nvim#plenarytest_harness.

Or just using neovim's screen.lua, like https://github.com/neovim/neovim/blob/89722ddfac51b0f7cbe5f4b0914e19ee9e8fdfd6/test/functional/ui/screen_basic_spec.lua#L48.

[d-r-a-b]

Sevoris and I were discussing this just the other day in dsicord, and it's nice to see that someone else is thinking along the same lines.

I recall from looking through the git history that tests were part of the github workflows/dev tree for a while and then were eventually stripped. My sense is that they may have been stripped because they had very high maintenance churn before norg-spec stabilized on 1.0. Given that the spec is now in a much more stable place, could a core dev comment on whether my sense is correct and whether they agree that re-implementation of a test suite makes sense at this time?

There are a fair number of behaviors for which you might need something closer to an integration test to test reliably. screen.lua looks like a promising choice; (neo)vim also includes :h testing for testing such behaviors although I find it slightly opaque. https://vimways.org/2019/a-test-to-attest-to/ is a very nice introduction to how YouCompleteMe author approached setting up a vim testing framework and goes into the basic ideas needed to implement a simplified version of the test framework ultimately used for the YouCompleteMe test suite, which is heavily inspired by the :h testing approach.

[vhyrro]

Yep now that we're past 1.0 I'm completely happy with implementing some form of advanced test suite. What would be fantastic is if each module could specify its own tests, for instance an individual module could have:

module.tests = {
	["Test name"] = function(fns)
		fns.some_assert(false, "whatever")
	end,
}

This way it can easily test public behaviours (whether the API is behaving correctly) and private behaviours (if the inside machinery works).

fns here could be a table with a handful of functions that a testing function may need, including stuff from screen.lua or whatever else.

After that I assume we implement :NeorgRunTests or something? I don't think it should belong in :Neorg ... because it's a feature exposed by the core, not by a module 🤔