Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NUnit1032 false positive when test class is static #607

Closed
NottsColin opened this issue Oct 11, 2023 · 2 comments · Fixed by #613
Closed

NUnit1032 false positive when test class is static #607

NottsColin opened this issue Oct 11, 2023 · 2 comments · Fixed by #613

Comments

@NottsColin
Copy link

NottsColin commented Oct 11, 2023

Discovered on NUnit.Analysers v3.8.0.

The following code raises NUnit1032 on the declaration of Enumerator.

using FluentAssertions;
using NUnit.Framework;

public static class ExampleTests
{
    private static readonly IEnumerator<string> Enumerator = new List<string>().GetEnumerator();

    [OneTimeTearDown]
    public static void TearDown()
    {
        Enumerator.Dispose();
    }

    [Test]
    public static void StubTest()
    {
        true.Should().BeTrue();
    }
}

I suggest that either NUnit1032 should not be raised at all as Enumerator is static, or it should be cleared by the existence of the TearDown function.

It seems to be the static keyword causing issues here. Making the class and the TearDown function non-static removes the NUnit1032 error.

edit: typos

@manfred-brands
Copy link
Member

Thanks @NottsColin for reporting this.

I don't think I ever used static test fixtures. Is there a particular reason for you doing so?

But I will amend the rule to detect static fixtures and deal with them appropriately.

Note that you will need to dispose in a OneTimeTearDown method.

@NottsColin
Copy link
Author

No problem!

I'm afraid I'm just maintaining some code rather than being the original author, so I can only speculate as to the reason for using static. I'm considering just making the tests non-static as a workaround for this issue in the short-term.

I suspect the reason for using static is because some static code analysers push for you to make things static as a default unless there is a reason it needs to be non-static. I think pragmatically, it's not a hill anyone would choose to die on either way :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants