path, xdg and error have no test files. The suite covers the type system
and environment and TOML:
test/type/ test_array test_boolean test_data test_dictionary test_number
test_string test_timestamp test_timezone test_to_string
test_type test_value
test/platform/ test_environment
test/format/ test_toml
src/platform/path.cpp and src/platform/xdg.cpp and src/type/error.cpp are
exercised only indirectly, if at all.
Why this is worth raising now
Three defects were found by reading those files rather than by running them, and
each would have been caught by a first test:
path::expand() lets a filesystem_error escape although it returns
std::expected; the process terminates. A single call on a path that does not
exist would have shown it.
path::mkdir() reports an existing directory as a failure, with an error whose
message is "Success". Calling it twice would have shown it.
path::exists() and the default path constructor call throwing
std::filesystem functions, so they can terminate on a permission problem or
a symlink loop.
The types that do have tests behave as documented, and where the documentation
was wrong the tests said so — value_cast_wrong_type pins the mismatch
behaviour of as<T>(), which is how that one was settled. The untested classes
are the ones whose documented behaviour turned out not to match the code.
Suggested starting point
Not full coverage, just the paths that already have known problems: constructing
a path from each supported form, append and string round-tripping,
mkdir twice, exists on a missing and a present path, expand and resolve
on a path that does not exist, an xdg instance with each accessor and with
XDG_* unset, and error construction from std::errc with domain, code
and message.
path,xdganderrorhave no test files. The suite covers the type systemand
environmentand TOML:src/platform/path.cppandsrc/platform/xdg.cppandsrc/type/error.cppareexercised only indirectly, if at all.
Why this is worth raising now
Three defects were found by reading those files rather than by running them, and
each would have been caught by a first test:
path::expand()lets afilesystem_errorescape although it returnsstd::expected; the process terminates. A single call on a path that does notexist would have shown it.
path::mkdir()reports an existing directory as a failure, with an error whosemessage is "Success". Calling it twice would have shown it.
path::exists()and the defaultpathconstructor call throwingstd::filesystemfunctions, so they can terminate on a permission problem ora symlink loop.
The types that do have tests behave as documented, and where the documentation
was wrong the tests said so —
value_cast_wrong_typepins the mismatchbehaviour of
as<T>(), which is how that one was settled. The untested classesare the ones whose documented behaviour turned out not to match the code.
Suggested starting point
Not full coverage, just the paths that already have known problems: constructing
a
pathfrom each supported form,appendandstringround-tripping,mkdirtwice,existson a missing and a present path,expandandresolveon a path that does not exist, an
xdginstance with each accessor and withXDG_*unset, anderrorconstruction fromstd::errcwithdomain,codeand
message.