diff --git a/AGENTS.md b/AGENTS.md index 289a343..d358253 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -27,7 +27,7 @@ Details are in **[CONTRIBUTING.md](CONTRIBUTING.md)**. Summary: - **Getting started:** Use the `Makefile` from the repository root; LuaRocks should use the user tree (see CONTRIBUTING). - **Commits:** Atomic commits, [conventional-commits](https://www.conventionalcommits.org/) format (type + scope, present tense, 50-char header, 72-char body). -- **Testing:** `make test` (Busted), `make lint` (LuaCheck). Coverage: LuaCov, output in `luacov.report.out`. +- **Testing:** `make test` (Busted), `make lint` (LuaCheck). Coverage: LuaCov, output in `luacov.report.out`. Every new feature, function, or component must be accompanied by tests where reasonable and applicable; exceptions are documented (see CONTRIBUTING). - **Documentation:** ldoc; sources in `config.ld`. Run `make docs` to generate; do not commit generated docs (`make clean` will revert generated docs). Update comments and examples during development. ## Test isolation @@ -62,6 +62,8 @@ In Busted test files in `./spec` the vertical whitespace is important: - 3 lines between initialization (`setup`/`teardown`/etc) and the first `it` or `describe` block - 1 line between multiple closing `end)` statements +For functionality that requires more than 3 cases of input to be tested, table-test-style is prefered. But only if it enhances maintainability and readability. + ## Architecture High-level design and module boundaries will be described in **[ARCHITECTURE.md](ARCHITECTURE.md)**. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 63d9b2b..02b8fd3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -77,6 +77,8 @@ Testing is done using the busted test framework, LuaCheck for linting, and LuaCo Use `make test` and `make lint` to run the tests. Coverage information will be in the file `luacov.report.out`. +In this library we adhere to a rigorous standard of quality: every feature, function, or component added to the codebase is accompanied by comprehensive tests, where reasonable and applicable. This ensures reliability, maintainability, and robustness, and provides a safety net for future changes. Exceptions to this rule are documented and justified, so that our development process remains transparent. + Be sensible, write tests, increase coverage.