Allow --minimum-expected-tests 0 (#7457)

[Evangelink]

Summary

Follow-up to #9709, part of #7457 (item #2). Allows the literal value --minimum-expected-tests 0.

Previously validation rejected 0 (value <= 0). It now rejects only negative and non-integer values. Combined with the zero-tests verdict governance in #9709, an explicit --minimum-expected-tests 0 accepts an empty run and returns exit code 0 — the same outcome the reporter asked for in #7457 (""--minimum-expected-tests 0 should have the same outcome as --ignore-exit-code 8""). It gives users an explicit, opt-in ""zero tests is acceptable"" escape hatch per test host.

Why this is separate from #9709

• Let explicit --minimum-expected-tests govern the zero-tests verdict (#7457) #9709 is the load-bearing change: it makes an explicit --minimum-expected-tests N return exit code 9 (not 8) even at zero tests, which the dotnet test orchestrator (Apply dotnet test zero-tests verdict at the whole-run level (microsoft/testfx#7457) dotnet/sdk#55167) relies on to normalize an empty module without swallowing a stricter local minimum. It does not depend on allowing 0.
• This PR is the user-facing item Porting latest changes. #2 feature and is not required by the SDK design. Splitting it keeps the SDK-critical change reviewable on its own.

Note: allowing a user-typed --minimum-expected-tests 0 is deliberately different from having the SDK auto-inject --min 0 into every module — the latter was rejected because older Microsoft.Testing.Platform versions reject --min 0 and the SDK cannot know a module's MTP version at argument-build time. Whoever types --min 0 explicitly owns that assumption.

Stacked on #9709

This PR targets the #9709 branch, because --minimum-expected-tests 0 + zero tests only resolves to success once #9709's verdict-governance logic is in place (otherwise the ZeroTests(8) verdict is computed first). Review/merge #9709 first; the diff here is only the validation change.

Change

• PlatformCommandLineProvider.IsMinimumExpectedTestsOptionValidAsync: reject only value < 0.
• Validation message: ""single non-zero positive integer"" → ""single non-negative integer"" (+ regenerated 13 PlatformResources.*.xlf via /t:UpdateXlf).

Tests

• PlatformCommandLineProviderTests: 0 / 1 / 10 now valid; negatives / non-integers still invalid.
• TestApplicationResultTests: --minimum-expected-tests 0 + zero tests → success.
• ExecutionTests (acceptance): --filter-uid matching nothing + --minimum-expected-tests 0 → exit code 0; negative-value validation-message expectation updated.

Unit tests pass locally (110/110 across TestApplicationResultTests + PlatformCommandLineProviderTests). Acceptance tests require -pack and run in CI.

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

[github-actions]

Note

🤖 Automated review by GitHub Copilot. Generated by the Expert Code Review workflow. To request a follow-up action, reply by tagging @copilot directly.

✅ 22/22 dimensions clean — no findings.

Summary: Clean, well-scoped change. The validation relaxation (value <= 0 → value < 0) is correct — when --minimum-expected-tests 0 is provided, the option's presence routes GetProcessExitCode() into the minimum-expected branch where _totalRanTests < 0 is always false, yielding ExitCode.Success and bypassing the zero-tests-policy check entirely. This is the correct design for an explicit "zero tests is acceptable" opt-in.

Tests thoroughly cover boundaries (negative, non-integer, zero, positive), both at the unit and acceptance integration level. Localization is properly done via .resx with XLF targets correctly marked needs-review-translation. Changelog updated. No public API surface change. No threading, security, or performance concerns.

[github-actions]

🧪 Test quality grade — PR #9724

5 test methods graded across 3 files, all earning A. The PR cleanly extends unit and acceptance coverage for the new --minimum-expected-tests 0 behaviour at every layer (unit, integration, and acceptance). Tests are well-named, well-commented, and assertive throughout.

Grade	Test	Notes
A (90–100)	mod ExecutionTests. Exec_ WhenMinimumExpectedTestsIsNegative_ ResultIsNotOk	Two assertions (exit code + output text) with a helpful inline comment; update aligns the expected string to the new validation wording.
A (90–100)	new ExecutionTests. Exec_ WhenMinimumExpectedTestsIsZeroAndNoTestsRun_ ResultIsOk	Well-named and commented; exit-code assertion is the complete observable verification for this acceptance scenario.
A (90–100)	mod PlatformCommandLineProviderTests. IsInvalid_ When_ MinimumExpectedTests_ Is_ Negative_ Or_ Not_ An_ Integer	Expanded DataRows (negative, float, empty, non-integer); dual assertions on validity flag and error message.
A (90–100)	new PlatformCommandLineProviderTests. IsValid_ When_ MinimumExpectedTests_ Is_ NonNegative_ Integer	Complements the invalid test; the IsValid check is the complete assertion for the happy path — no error message to also verify.
A (90–100)	new TestApplicationResultTests. GetProcessExitCodeAsync_ If_ MinimumExpectedTests_ Zero_ And_ No_ Tests_ Ran_ Returns_ Success	Well-commented with issue reference; exit-code equality check is exactly right for the zero-minimum scenario.

_{This advisory comment was generated automatically. Grades are heuristic
and informational — they do not block merging. Re-run with
/grade-tests.}

🤖 Automated content by GitHub Copilot. Generated by the Grade Tests on PR (on open / sync) workflow. · 92.2 AIC · ⌖ 13.6 AIC · ⊞ 9.5K · [◷]( · ◷)