After looking at the amount of code involved, I'm reluctant to take on the maintenance burden that this would imply, for a feature that nobody has asked for. Switching your filters from VSTest to MTP is probably a relatively small amount of the effort involved in switching, and we wouldn't want to encourage people to use the outdated and aging filter syntax when superior options exist.

I believe that this feature probably belongs in core MTP rather than here, if this is a burden in moving from VSTest to MTP, since it would affect all testing frameworks and not just xUnit.net.

@bradwilson If we provide a source package with all the code in VSTestFiltering directory of this PR, would you be willing to accept this PR?

See also modelcontextprotocol/csharp-sdk#1011

Who would write and maintain this library?

Also, I am negatively motivated by "the AI bots are having a hard time" since I believe use of AI is at best unethical and and worst immoral.

Who would write and maintain this library?

I'm thinking of having this in VSTest repo, so that VSTest is the single source of truth.

This will also mean that we will be able to delete the relevant parts that we copied from vstest repo to the VSTestBridge implementation in testfx, which would be a win for us to avoid the duplication and double maintenance.

And presumably test frameworks would need to implement something like we did for VSTest: https://github.com/xunit/visualstudio.xunit/blob/main/src/xunit.runner.visualstudio/Utility/TestCaseFilter.cs

@bradwilson That would be the logic in XunitFilters.cs in this PR. The core of it is this part which provides the values of properties.

			var filterExpression = new TestCaseFilterExpression(new FilterExpressionWrapper(vstestFilter));

			return filterExpression.MatchTestCase(propertyName =>
			{
				if (string.Equals(propertyName, "FullyQualifiedName", StringComparison.OrdinalIgnoreCase))
				{
					if (testCase.TestClassName is null || testCase.TestMethodName is null)
					{
						return null;
					}

					return $"{testCase.TestClassName}.{testCase.TestMethodName}"; // TODO: Should we add backtick and arity here?
				}
				else if (string.Equals(propertyName, "DisplayName", StringComparison.OrdinalIgnoreCase))
				{
					return testCase.TestCaseDisplayName;
				}

				_ = testCase.Traits.TryGetValue(propertyName, out var values);
				return values?.ToArray();
			});

Having a singular implementation of the filter parsing (that is owned by Microsoft) certainly alleviates the maintenance concern.

Great. I'll discuss with the team next week (or a bit after, depending on priorities).

Any progress here?

Unfortunately, not yet.

Hi @bradwilson

We merged microsoft/vstest#15638

I updated the PR to use it.

Integration here looks pretty simple on the surface. This seems like a reasonable POC. Once I know more about when we can count on this code coming from NuGet, then I'll look at moving this PR over to the rel/4.0.0 branch.

@Youssef1313 @nohwnd I would like to get this integrated into 4.0, and I'm planning to do what I hope is a final prerelease this coming weekend, but I'm reluctant to take this dependency on a non-NuGet based source package (without the NuGet guarantee that the package will never be deleted).

I have a version of this PR pushed to this branch: https://github.com/xunit/xunit/compare/rel/4.0.0...VSTestFilter?expand=1

This updated branch:

• Targets rel/4.0.0 rather than main
• Copies the source files from the NuGet package rather than take the dependency (until such time as the dependency is available on NuGet.org)
• Adds -filterVSTest to the in-process runner command line
• Adds missing unit tests

I've chosen not to add -filterVSTest to xunit.v3.runner.console at this time, due to the complications of trying to support it (or throw) for older projects. I suspect that -filterVSTest will not be frequently used, so I don't anticipate this to be an issue for most users, since it's expected that the primary use of this feature is via dotnet test or the MTP UX and --filter.

In-process console runner help:

dotnet test help:

I'm just going to merge my branch as-is on the trust that the NuGet package will eventually show in the right place (or else the "implementation" of this feature will be frozen in time).

Commit is here: 0765f56

Available in v3 4.0.0-pre.107 https://xunit.net/docs/using-ci-builds

Going to leave this PR open so I don't forget to periodically check for a release version of the NuGet package.

@Youssef1313 @nohwnd Any hints on when an official package might show up on NuGet?

@nohwnd Looks like VS 18.7 got released, but VSTest 18.7 isn't.

https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-notes#18.7.1

Should VSTest 18.7 ship to nuget.org now? this release, I think, should contain the new package.

18.7 is planned for tomorrow.

Using the public NuGet package 1ef36bd