Is it necessary to enable nullable context in unit tests?

Question

I have an Asp.net Core 6 Web Api project.

I am trying to protect against NullReferenceException.

I have added the following setting to all projects:

<Nullable>enable</Nullable>

I have fixed the code base, but I get warnings in Unit and integration tests:

**viewModel**.Message.Should().Be("Aaaa");

viewModel is underlined for a possible null reference.

I think enabling this feature for unit tests is useless. When you write the unit test, you set up the conditions - so you know if something is null.

Instead of putting the "!" (damnit) operator everywhere to tell the compiler I am sure it is not null, I believe I should just remove the <Nullable>enable</Nullable> setting from test projects.

Does anyone see a valid reason <Nullable>enable</Nullable> should stay in Unit test projects?

Springer

Answer 1

Finally, I decided to use the following setting in the tests projects:

<Nullable>annotations</Nullable>

Because as described here, it will disable null-reference warnings, but it will also allow me to use the T? type in the tests. Since I have fake values which I pass to the methods to which I on purpose assign the null value, I want to have the freedom to declare them as T?

IEnumerable<Foo>? collection = null;
a.DoSomething(collection); 

I decided not to use annotations because it does not allow me to declare variables as T?.

Springer

Answer 2

Assuming your unit test project is separate from the project where the code is being tested, the setting should at least match the configuration of the project being tested.

If the nullable reference types are enabled in the project being tested then there is no harm in enabling it for the unit tests.

However nullable reference types are disabled in the project being tested and enabled in the unit tests project, this might lead to a scenario where a unit test passes but there is a bug (e.g. null reference exception) in the code the unit test is testing.

You never want unit tests to pass when there is a problem in the code since the whole point of them is to alert you to issues in the code.

The most safe option is to disable nullable reference types in the unit test project regardless of the setting in the project being tested. This way you are protected if the setting is changed.

Arela

How will enabling nullable result in passing unit tests? Nullable only tells the compiler to do some checking. If a reference is null at runtime, while not expected at compile time, it will still result in a null reference exception, right? – Bracing

@Bracing it may cause someone to resolve the warning by assigning a value to nullable object instead of leaving it null, thus preventing the checking of the null case where there may be an issue. Quite nuanced but still nevertheless important. – Arela

Answer 3

I would <Nullable>disable</Nullable> the unit test project.

My preference would be for a unit test to fail if anything is null, otherwise I might miss out on a codepath that is not working as expected. I see a unit test as something that should send alarm bells ringing at any conceivable moment, as I would rather a unit test fail in front of me in preference to a production error that I have to bugfix later on.

Euphrasy

disable will save me the "!" operator. However, I have parameters which I pass to the tests which I deliberately instantiate as null to see how my methods behave: IEnumerable<Foo>? collection = null; a.DoSomething(collection); Because of this - isn't the annotations context better for unit tests? With disable - I get a warning when I try to denote a collection as nullable. – Springer

Instead of <Nullable>disable</Nullable> (which would disable them in the entire project), it would also be possible to disable them only in the code blocks where we want to submit a null value using #nullable disable / #nullable restore – Aweigh