TUnit0018: What's wrong with mutating instance fields?

[AArnott]

According to the test lifecycle overview, each test is executed within the context of a unique instance of the test class. Why then, is it not advisable to mutate instance fields on the class? That seems perfectly safe, and occasionally useful.

I find it particularly shocking that the analyzer advice is:

Test methods should not assign instance fields/properties - consider using static fields or [NotInParallel]

Why on earth would it be preferable to mutate static fields? That would certainly cause concurrency issues with other tests.

[thomhurst]

You're right - You can. That warning is to make the code clear on intent. People may think that fields are seen by all tests, which isn't the case, and so the static keyword makes that clear.

If a test has a value, why does it need to persist it in a field? It's setting the value just to retrieve it again?

You can use fields, that analyzer was just an attempt to make things clearer to people.

[AArnott]

Thanks for the quick response. I'll just turn off that diagnostic code then.

I don't mutate fields often. But a lot of my tests call other helper methods to share logic, and rather than pass test-specific values through every method, sometimes it's just more convenient to set a property that the final helper method can just read. That way, a default can be set on the property, and tests can override it if they need to. And I don't have to tunnel that value all the way through to the final helper method.