Repository navigation
test(downgrader): cover a 3.2 security requirement name holding undefined - #334
Conversation
…and repeated keywords beside properties Stryker on 94c60c7 leaves 77 mutants alive where 0.5.0 left 70. Seven of the new ones are untested branches from #313, #314 and #318: - cutHolders.clear() removed: a $ref object cut in one call still tells no oneOf branch apart in the next. - follow's check for a $ref into a target being inlined removed: a $ref to a component whose own $ref into that target is cut only later keeps a oneOf whose branches now overlap. - isOneWay ignoring writeOnly, or not following a $ref to the tag. - repeats(): a repeated additionalProperties beside the same properties, and another keyword beside different properties. - mayRepeatUnseen counting null as an object. Each of these mutants now fails a test. No source change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VVaw7RYWCsn8myBE4Rncuq
…me holds undefined #324 keeps a requirement name only when components.securitySchemes has it as an own key, so a scheme entry holding undefined, as spreading options often leaves, still counted as a scheme. The 3.1 output leaves that entry out, so the requirement named a scheme the document no longer defines, and the same input with the key deleted gave a different output. The check now also needs the entry to hold a value, as every other key holding undefined counts as missing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VVaw7RYWCsn8myBE4Rncuq
…ined Since #331 a scheme holding undefined fails the scheme check first, so the oRPC undefined-key test no longer reaches the check that leaves out a requirement name holding undefined, and Stryker leaves that mutant alive. A requirement name holding undefined whose scheme exists now must come out as a missing key. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VVaw7RYWCsn8myBE4Rncuq
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
convertSecurityundefined-name coverage — the existing "leaves out security requirement names that are not a component name" test gains a second requirement{ key: undefined }, and the assertion is tightened fromtoEqualtotoStrictEqualso an ownkeyholdingundefinedis observable. This kills the Stryker survivor onrequirement[name] !== undefinedinv3.2-to-v3.1.ts:184that #331 reintroduced.
I verified the affected test passes (vitest run tests/v3.2-to-v3.1.test.ts -t "leaves out security requirement names"), and confirmed the expectation matches convertSecurity: requirement[name] !== undefined && isScheme(name) drops the undefined-valued name, and Object.fromEntries leaves no key behind, yielding {} for the second requirement.
deepseek-v4.1-flash (free via Pullfrog for OSS) | 𝕏
Merging this PR will not alter performance1 warning
Comparing Footnotes
|

🤖 Generated with Claude Code
https://claude.ai/code/session_01VVaw7RYWCsn8myBE4Rncuq
Test-only. Stryker on main (55c2570) has one survivor that #331 introduced:
requirement[name] !== undefined→truein the 3.2convertSecurity.Before #331, the oRPC undefined-key test (which adds
missing: undefinedto every object) killed that mutant.isScheme('missing')was true then, becausesecuritySchemeshad the key, so only the requirement check removed the name. Since #331,isSchemeis false for a scheme holding undefined, so the requirement check is never reached.The #331 test now also has a requirement
{ key: undefined }whose scheme exists, and checks the result withtoStrictEqual. Without the check, the output keeps an ownkeyholding undefined, which a tool listing the requirement's keys would read as a needed scheme.expected [ { key: [] }, { key: undefined } ] to strictly equal [ { key: [] }, {} ].pnpm run checkpassed.Generated by Claude Code