This is a simple computation over the JSON structure of the schema,
so it doesn’t need pulling in another programming language and a
dependency on an external C program to interpret it.
This removes an external tool dependency, skips the complexities
of subprocessing, and avoids having to poke a hole in the macOS
Nix sandbox because of `reqwest` trying to read the system’s TLS
configuration.
Note that despite the `Cargo.lock` getting bigger, this is actually a
net reduction of dependencies, as Taplo is written in Rust and pulls
in not only `jsonschema` but much more besides.
While the existing test checks that the schema defaults are consistent
with the output of `jj config get` (with default config), it would not
find type errors like the ones fixed in e9da94e.
This add another test case which validates the synthetic TOML containing
the default values according to the schema against the schema itself.
Because the datatests don't use the default libtest harness, datatests
and normal tests cannot be mixed in the same module or even binary.
`test_config_schema` is renamed, both to reflect that it is unlike the
other `test_*` modules, but also to make the name available for "normal"
tests related to the config schema.
A pattern has emerged where a integration tests check for the
availability of an external tool (`git`, `taplo`, `gpg`, ...) and skip
the test (by simply passing it) when it is not available. To check this,
the program is run with the `--version` flag.
Some tests require that the program be available at least when running
in CI, by calling `ensure_running_outside_ci` conditionally on the
outcome. The decision is up to each test, though, the utility merely
returns a `bool`.
Adds a bunch of additional sample config toml files. Via the
`datatest_runner`, these each correspond to a test case to check that
the toml is correctly (in-)validated according to the schema.
The `valid/*.toml` files typically define multiple related config
options at once. Where there's some overlap with the default configs in
`cli/src/config`, the aim was to choose different allowed values, e.g.
hex colors, file size in bytes (numeric), etc.
The `invalid/*.toml` files typically only define a single offending
property such as to not obscure individual false negatives. All of the
"invalid" files are still valid toml as the aim is not to test the
`toml_edit` crate or Taplo.
The sample files all contain a Taplo schema directive. This allows them
to be validated against the schema on the fly by Taplo's LSP and derived
IDE plugins to speed up editing and immediately highlight offending
options.
Closes#5695.
The `datatest-stable` crate allows to dynamically instantiate test cases
based on available files. This is applied to `test_config_schema` to
create one test case per config file. As case in point, the test case
for `hints.toml` was missing previously, hence the total number of tests
is up one.
This will become useful when adding more config examples to somewhat
exhaust the schema.
`datatest-stable` uses a custom test harness and thus cannot be used in
the same integration test binary that all of the other test modules run
in. However, if data-driven tests are to be used for other applications,
they can share in the same binary, so the module structure is already
set up to mirror the central "runner" approach.
