Repository navigation
Fix dotnet test validation with explicit paths - #56375
Merged
Merged
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
…ryleve/dotnet-test-cli-isolation
…ryleve/dotnet-test-cli-isolation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Azure Pipelines: Successfully started running 1 pipeline(s). 2 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Add equivalent regression coverage for --solution and --test-modules.
Get a fresh assessment by requesting another Copilot review.
Review effort: Lite
Findings: 1
Open (1)
What changed in this PR
Updates dotnet test validation so forwarded project-like arguments are not misclassified when an explicit build path is supplied.
Changes:
- Suppresses misleading diagnostics for explicit project, solution, or test-module paths.
- Adds regression coverage for
--projectwith and without--.
| File | Summary |
|---|---|
test/dotnet.Tests/CommandTests/Test/GivenDotnetTestBuildsAndRunsTestsWithDifferentOptions.cs |
Adds regression tests for forwarded project-like arguments. |
src/Cli/dotnet/Commands/Test/MTP/TestCommandOptions.cs |
Adjusts positional-path validation for explicit build options. |
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). 2 pipeline(s) were filtered out due to trigger conditions. |
Evangelink
enabled auto-merge (squash)
September 23, 2026 20:48
YuliiaKovalova
approved these changes
Sep 24, 2026
3 of 7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
dotnet testprovides helpful validation when a project, solution, directory, or test module is passed as a non-first unmatched argument. That validation is misleading when an explicit build path such as--projectis already present, because subsequent unmatched tokens belong to the test application and may legitimately name an existing path.This change keeps positional inference and duplicate-path validation intact, but skips the non-first path diagnostic when
--project,--solution, or--test-moduleshas already selected the build input. As a result, extension option values behave consistently with and without the--separator.Coverage includes the end-to-end
--projectscenario from #56369 in both forms, plus direct parser cases for all three explicit build-path options with and without the separator. Existing validation tests continue to verify the helpful diagnostics when no explicit build path is supplied.Related to #56338. The .NET 10 servicing fix is in #56374.