You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would auto-generate a #[cfg(test)] #[test] fn conf_test_MyStruct() { ... }, so you don't have to type any boilerplate yourself, and any options we were going to stick on the builder, we can make proc-macro arguments instead.
Tests we can run include:
Run clap::Command::debug_assert()
Check that short flags, long flags, serde names, don't collide. (But allow whitelisting some or all collisions)
Check if default_value actually parses without errors according to value_parser.
Recursively test subcommands
This can make it more natural to do certain things. For example, testing the default_value with the value_parser should usually work. But, if the value_parser reads a file, the test may fail if the file isn't there, and it may create a burden to make the test actually pass. In that case you might like to have a way to skip that test.
With a proc-macro attribute to control the testing, you can put #[arg(test(skip_value_parser_default_value))] on the problematic field.
Without proc-macro support, you have to find an unambiguous way to identify the field to the builder, or you have to use a mix of the builder API and the proc-macro attribute API, which seems messier.
The text was updated successfully, but these errors were encountered:
We should have something similar to
clap::Command::debug_assert()
,See also this discussion: #5
After pondering it for a while, I think that instead of exposing a special builder for this, we should just expose a proc macro attribute, so like
This would auto-generate a
#[cfg(test)] #[test] fn conf_test_MyStruct() { ... }
, so you don't have to type any boilerplate yourself, and any options we were going to stick on the builder, we can make proc-macro arguments instead.Tests we can run include:
clap::Command::debug_assert()
default_value
actually parses without errors according tovalue_parser
.This can make it more natural to do certain things. For example, testing the
default_value
with thevalue_parser
should usually work. But, if thevalue_parser
reads a file, the test may fail if the file isn't there, and it may create a burden to make the test actually pass. In that case you might like to have a way to skip that test.With a proc-macro attribute to control the testing, you can put
#[arg(test(skip_value_parser_default_value))]
on the problematic field.Without proc-macro support, you have to find an unambiguous way to identify the field to the builder, or you have to use a mix of the builder API and the proc-macro attribute API, which seems messier.
The text was updated successfully, but these errors were encountered: