Assert.AreEqual()运行结果不可靠单测通过全量运行时预期值异常

AI 小北

2026-9-29

问题原因排查方向

断言参数顺序倒置 + LINQ延迟计算+共享数据源污染
绝大多数C#单元测试框架（NUnit、MSTest、xUnit）的相等断言方法，参数顺序为Assert.AreEqual(预期值, 实际值)，你当前的写法将实际值descendants.Count()放在了第一个参数位，字面量2放在了第二个参数位，本身就存在参数倒置的问题。
你所描述的「确认descendants.Count()每次返回2」一般是单独调试测试的结果，批量执行测试时，前序测试很可能已经修改了descendants关联的数据源。而descendants本身是LINQ延迟查询，直到断言执行时才会真正计算结果，这时候拿到的是被其他测试修改后的脏数据，返回值为0，和第二个参数位的预期值2不匹配，就会出现你看到的「预期值<0>，实际值<2>」的报错。
共享变量被其他测试修改
如果你代码里的预期值不是写死的字面量2，而是来自测试类的静态变量、全局共享配置对象，可能其他测试用例修改了该变量的值为0，批量执行时你的测试拿到了修改后的值作为预期值，才会出现预期值偶发变为0的情况。
测试上下文未做隔离重置
如果你没有在测试生命周期前置钩子（NUnit的[SetUp]、xUnit的构造函数、MSTest的[TestInitialize]）中重新初始化所有测试用到的数据源、业务对象实例，前序测试对共享实例的修改会一直残留到后续测试执行，最终导致上下文污染。