Language
Edit

MSTEST0063: Test classes should have valid constructors

Property Value
Rule ID MSTEST0063
Title Test classes should have valid constructors
Category Usage
Fix is breaking or non-breaking Non-breaking
Enabled by default Yes
Default severity Warning
Introduced in version 4.1.0
Is there a code fix No

Cause

A test class doesn't have a valid constructor. Without host-owned test-class injection, valid constructors are public and either parameterless or have a single parameter of type TestContext. With host-owned injection, the rule also validates public constructor availability, preferred constructors, and TestContext parameter types.

Rule description

Without host-owned test-class injection, test classes must have a public constructor that is either parameterless or accepts a single TestContext parameter. This allows the test framework to instantiate the test class properly.

In that mode, constructors that are non-public, have parameters of unsupported types, or have multiple parameters aren't valid and prevent the test framework from creating instances of the test class.

[TestClass]
public class MyTestClass
{
    private MyTestClass() // Violation - constructor is not public
    {
    }
}

[TestClass]
public class MyTestClass
{
    public MyTestClass(string value) // Violation - parameter type is not supported
    {
    }
}

[TestClass]
public class MyTestClass
{
    public MyTestClass(TestContext testContext, int value) // Violation - multiple parameters
    {
    }
}

Host-owned test-class injection

Starting with MSTest 4.5, the experimental MSTest.Extensions.Hosting package supports test-class construction from host services. When you register AddMSTestTestClassInjection, public constructors can accept service parameters and an optional exact TestContext parameter.

In this mode, MSTEST0063 reports a diagnostic when:

  • The test class doesn't have a public constructor.
  • More than one public constructor declares ActivatorUtilitiesConstructorAttribute.
  • A public constructor has a parameter whose type derives from TestContext, rather than TestContext itself.

The analyzer also recognizes host-owned injection enabled through a referenced assembly that records the registration. It doesn't verify that the host registers every service required by a constructor.

To fix these violations, expose a public constructor, mark at most one public constructor with [ActivatorUtilitiesConstructor], and replace derived TestContext parameter types with TestContext. If you disable host-owned injection, use the standard constructor forms described in the next section. For unsupported build modes, see MSTEST0088.

How to fix violations

Without host-owned test-class injection, ensure your test class has a valid constructor. A valid constructor must be:

  1. Declared as public.
  2. Either parameterless or accepts a single TestContext parameter.

Parameterless constructor

[TestClass]
public class MyTestClass
{
    public MyTestClass()
    {
    }

    [TestMethod]
    public void TestMethod()
    {
    }
}

Constructor with TestContext

[TestClass]
public class MyTestClass
{
    private readonly TestContext _testContext;

    public MyTestClass(TestContext testContext)
    {
        _testContext = testContext;
    }

    [TestMethod]
    public void TestMethod()
    {
        _testContext.WriteLine("Test is running...");
    }
}

Implicit parameterless constructor

If you don't define any constructor, the compiler generates a public parameterless constructor automatically:

[TestClass]
public class MyTestClass
{
    [TestMethod]
    public void TestMethod()
    {
    }
}

Valid and invalid constructors together

If your test class has multiple constructors, at least one must be valid:

[TestClass]
public class MyTestClass
{
    public MyTestClass() // Valid - this makes the class valid
    {
    }

    private MyTestClass(int x) // Invalid, but ignored because a valid constructor exists
    {
    }

    [TestMethod]
    public void TestMethod()
    {
    }
}

When to suppress warnings

Don't suppress warnings from this rule. Test classes without valid constructors can't be instantiated by the test framework, and the tests won't run.

Suppress a warning

If you just want to suppress a single violation, add preprocessor directives to your source file to disable and then re-enable the rule.

#pragma warning disable MSTEST0063
// The code that's violating the rule is on this line.
#pragma warning restore MSTEST0063

To disable the rule for a file, folder, or project, set its severity to none in the configuration file.

[*.{cs,vb}]
dotnet_diagnostic.MSTEST0063.severity = none

For more information, see How to suppress code analysis warnings.

See also

  • Last updated on