-
-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unit tests #835
Comments
Or just using neovim's screen.lua, like https://github.com/neovim/neovim/blob/89722ddfac51b0f7cbe5f4b0914e19ee9e8fdfd6/test/functional/ui/screen_basic_spec.lua#L48. |
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 There are a fair number of behaviors for which you might need something closer to an integration test to test reliably. |
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).
After that I assume we implement |
Issues
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
The text was updated successfully, but these errors were encountered: