单元测试项目是否有必要启用<Nullable>enable</Nullable>可空上下文？

当然有合理理由保留，不是非删不可：

• 别觉得测试代码是自己写的、前置条件全自己控就不会出空引用问题。实际写测试的时候漏配Mock返回值、构造测试数据少了字段、Setup逻辑写漏分支都是常有的事，开着可空上下文编译期就能揪出一大半这种低级错误，总比跑测试的时候抛个没头没脑的NullReferenceException，debug半天才发现是自己写测试时手滑漏了配置强。
• 你觉得要到处堆!（就是大家戏称的damnit运算符）太烦，本质是没找对消警告的正确方式，不是可空特性的锅。就拿你举的viewModel的例子，根本不需要在访问属性的时候硬加!，拿到结果第一行先做非空断言就行：

  var viewModel = await sut.GetTargetViewModel();
  viewModel.Should().NotBeNull(); // 目前主流版本的编译器和FluentAssertions能识别这个断言的非空校验语义
  viewModel.Message.Should().Be("Aaaa"); // 这行就不会再跳空引用警告了
  

  而且这种写法比加!靠谱多了：!只是你跟编译器拍胸脯保证“这东西绝对不为空”，真到运行时碰到null该炸还是炸；Should().NotBeNull()是实打实会在运行时做校验，真出问题直接给明确的测试失败提示，排查成本低太多。
• 测试项目里的公共代码也需要可空约束。只要测试项目不是全是十几行的独立小用例，一般都会抽公共测试辅助方法、测试数据构造器、通用Mock逻辑，这些代码是所有写测试的同事都会复用的。开着可空上下文，这些公共方法的入参、返回值能不能为null是明明白白的，哪天改公共逻辑不小心漏了分支返回null，或者同事调用的时候乱传null，编译期就能报警，不会等跑测试炸了才回头找问题。

当然这东西没有必须遵守的铁律：如果你们团队的测试项目全是短小独立的用例，没有公共复用代码，所有人都觉得处理可空警告的成本比编译期查错的收益高，直接关了测试项目的可空配置也完全没问题，这类工程配置本来就是优先适配团队的开发习惯，没有绝对的对错。

内容的提问来源于stack exchange，提问作者MiBuena