fix: test suites that never ran, and thirty expectations that assert nothing

[awsmadi]

Four test-suite fixes in this repository. Three suites were never run at all, thirty expectations asserted nothing, and two case titles state the opposite of what their case tests. Nothing here changes a rule, and no .guard file is touched.

Thirty expectations that assert nothing

rules/aws/aws_cloudformation/tests/cfn_no_explicit_resource_names_tests.yml carries 63 expectation entries across 33 cases. Thirty of them name rules that do not exist, spread over 11 distinct names:

no_static_names, static_alarmname, static_dbinstanceidentifier, static_deploymentconfigname, static_deploymentgroupname, static_domainname, static_groupname, static_managedpolicyname, static_name, static_repositoryname, static_rolename

cfn_no_explicit_resource_names.guard defines exactly one rule, CFN_NO_EXPLICIT_RESOURCE_NAMES. For each of the thirty, cfn-guard test prints

No rule named static_rolename is in this file, so its expectation was not checked

and exits 0. So the suite has always reported clean while those thirty assertions ran nothing.

They are not a stale rename. Both files were added in the same commit, 5f4a972 (#265), and no commit since renames a rule. The eleven names are the intended decomposition of the rule into per-type checks, written into the test file although the decomposition was never written into the rules file. Each maps onto the property one type block checks — static_name to Name, static_alarmname to AlarmName, and so on.

Dropped rather than repointed, because every affected case already carries a CFN_NO_EXPLICIT_RESOURCE_NAMES expectation of its own. Renaming a dead entry onto the rule that exists produces a second copy of an assertion the case already makes, so the two operations are equivalent here and deletion is the smaller diff. No test input is removed: all 33 cases still run, against the same templates, asserting the same aggregate verdict.

What is lost is the granularity those eleven names wanted, and it is worth having — a per-type verdict says which resource type caused a failure, and lets one type be suppressed without suppressing the whole rule. Restoring it means adding per-type rules to the ruleset, which changes the public rule set and needs a cfn-guard that tolerates a rule reference to a rule that did not apply. That is a follow-up, not this change.

No case covered more than one resource type

Every one of the 33 original cases declares exactly one resource of exactly one covered type. So nothing in the suite ever distinguished the rule's fourteen type checks from each other, and nothing exercised the rule on a template carrying several of them — which is what a real template looks like.

Three cases are added for that: several covered types all clean, several with one violating, and several with more than one violating. The middle one is the shape that matters, because it is the only case in the suite where the aggregate must fail on account of one specific type while the others are fine.

Three suites that never ran

cfn-guard test pairs a test file to a rules file by name. Three test files were named so that no rules file claimed them, so they were silently skipped:

• cloudfront_accesslogs_enabled_tests.yml — renamed to match its rule
• iam_role_no_full_access_on_trust_policy_tests.yml — renamed to match its rule
• s3_bucket_default_lock_enabled_tests.yml — renamed to match its rule

rds_instance_logging_enabled_tests.yml is removed: it duplicates rds_logging_enabled_tests.yml, which is paired and does run.

Two titles that describe the wrong outcome

Two cases in cfn_no_explicit_resource_names_tests.yml are titled as the opposite of what they assert. Titles only, no expectation changed.

Verification

cfn-guard test -d ./rules/ — the invocation .github/workflows/ci.yml uses — before and after, on the released cfn-guard and on a build from main:

	expectation entries	entries naming a rule that does not exist
before	63	30
after	36	0

Exit code is 0 before and after on every cfn-guard version tested, so this does not depend on a tool release. The reduction from 63 to 36 is the thirty dead entries plus the deduplication described above; case count goes from 33 to 36 with the three new ones.

Every .guard file in the repository parses to a byte-identical tree before and after, because none is modified.

[awsmadi]

CI has never executed here — the workflow runs are held at action_required pending maintainer approval, so there are no results to read either way.

That matters more than usual for this one, since the change is specifically about test suites that never ran and expectations that assert nothing. Without a CI run there is no evidence the newly-armed expectations actually fire. Could a maintainer enable the workflow run?