-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Check that all configuration options are tested in all.sh #3417
Comments
I just thought of an easier way to do it: we can piggyback on the existing mechanism for testing that all test cases have been executed during outcome analysis. For each configuration option, automatically emit two test cases
where We already have scripts that enumerate all configuration options ( |
all.sh
runs build+test cycles with various configurations. We can't test all combinations ofconfig.h
symbols, but we should test all the relevant ones.The goal of this issue is a step along the way: for every configuration option in
config.h
, check whether there is at least one build+test run with it enabled and one with it disabled. The runs can be as a component inall.sh
, or via adepends-xxx
script. The minimum deliverable to fulfill this issue is a list of configuration options that aren't covered both ways. Ideally this list should be checked mechanically.For example, any option that is off by default but enabled in
full
is already covered both ways. Any option that is on by default but disabled in adepends
run is already covered both ways. Any option that is disabled infull
and not covered by a separate component inall.sh
is not covered on. Any option that is enabled by default and never disabled in any test run is not covered off.When working on this issue, it would be useful to make a pass of reviewing
all.sh
components, and check if some of them may be fully or partially redundant. For example,component_test_variable_ssl_in_out_buffer_len_CID
is mostly redundant since it's default plus options that are enabled infull
.In other words, this issue is about enabling and disabling options individually. Some combinations of options need to be tested, but that's out of scope. To go further, cppcheck may help with figuring out which option combinations lead to different code in a module. Measuring code coverage could also help (ideally, all code lines should be built at some point, although realistically some platform-specific lines and aren't going to run on our CI ever).
Related: #2691 and #2002 — but they're about making sure that all test cases are executed. This is about trying out configurations that may not have specific test cases (they may be tested through test code that works whether or not these options are enabled).
Definition of done: if an option is never enabled or never disabled in
all.sh
, this causes a CI failure. There may be exceptions; legitimate exceptions (e.g. platform-specific settings for platforms we don't test) must be whitelisted with an explanation, and non-legitimate exceptions (we should test XXX but we don't) may be whitelisted with a link to a GitHub issue requesting extra test coverage.The text was updated successfully, but these errors were encountered: