Description:
In MSTest v3, a [TestCategory] attribute placed on a concrete subclass would propagate to all [TestMethod]s inherited from a base class. This allowed filtering inherited tests by category at runtime. This behavior appears to have been removed in MSTest v4 without a documented migration path.
Steps to reproduce:
Run with filter: TestCategory!=IgnoreInCI
Expected behavior (MSTest v3):
ConcreteTestRunner.MyTest is excluded by the filter because the category propagates from the class to inherited methods.
Actual behavior (MSTest v4):
ConcreteTestRunner.MyTest is not excluded — the category on the class does not propagate to inherited methods, only to methods physically declared in that class.
Impact:
This is a silent breaking change. Any test suite that uses inheritance-based test organization (a common pattern for running the same test logic against multiple environments/configurations) will have its category-based filtering silently broken after upgrading to v4, with no compile-time warning.
In our case, this caused SelfHost E2E tests (which require a locally-running service) to run on CI/rolling build machines, producing Service Unavailable failures across multiple test assemblies.
Workaround:
We are currently using a FullyQualifiedName filter at the infrastructure level to exclude affected classes by name convention, which is fragile and not scalable.
##Questions:
Is this change intentional? If so, what is the recommended migration path?
Is there a supported way to apply [TestCategory] to inherited methods based on the concrete subclass?
Environment:
- MSTest version: v4 (upgrading from v3)
- .NET version: net8.0
- OS: Windows
Description:
In MSTest v3, a [TestCategory] attribute placed on a concrete subclass would propagate to all [TestMethod]s inherited from a base class. This allowed filtering inherited tests by category at runtime. This behavior appears to have been removed in MSTest v4 without a documented migration path.
Steps to reproduce:
Run with filter: TestCategory!=IgnoreInCI
Expected behavior (MSTest v3):
ConcreteTestRunner.MyTest is excluded by the filter because the category propagates from the class to inherited methods.
Actual behavior (MSTest v4):
ConcreteTestRunner.MyTest is not excluded — the category on the class does not propagate to inherited methods, only to methods physically declared in that class.
Impact:
This is a silent breaking change. Any test suite that uses inheritance-based test organization (a common pattern for running the same test logic against multiple environments/configurations) will have its category-based filtering silently broken after upgrading to v4, with no compile-time warning.
In our case, this caused SelfHost E2E tests (which require a locally-running service) to run on CI/rolling build machines, producing Service Unavailable failures across multiple test assemblies.
Workaround:
We are currently using a FullyQualifiedName filter at the infrastructure level to exclude affected classes by name convention, which is fragile and not scalable.
##Questions:
Is this change intentional? If so, what is the recommended migration path?
Is there a supported way to apply [TestCategory] to inherited methods based on the concrete subclass?
Environment: