xunit.net：为何不使用静态构造函数替代IClassFixture实现共享状态？

不是必须用IClassFixture<T>，但静态构造函数的方案存在不少容易踩坑的弊端，远不如官方推荐的方式靠谱：

• 生命周期完全不可控：静态构造函数是CLR自动触发的，第一次访问测试类时就会执行——哪怕只是测试探索阶段扫描到这个类，都会提前初始化资源，导致资源被长时间占用。而IClassFixture<T>的生命周期由xUnit全权管理：测试类的所有测试开始前创建实例，所有测试跑完后立即销毁（如果T实现了IDisposable），时机精准可控。

• 并行测试下的线程安全隐患：xUnit默认支持并行测试，静态成员是跨线程共享的。如果多个测试类用了静态构造函数，或者同一个测试类的测试并行执行，很容易出现并发修改共享状态的问题，导致测试结果随机失败，排查难度极大。而IClassFixture<T>的实例是每个测试类专属的（集合级别的ICollectionFixture则是每个测试集合一个），xUnit会保证在单线程内处理该fixture的初始化和测试执行，从根源避免并发冲突。

• 测试隔离性差，结果不稳定：静态状态一旦初始化，除非手动写代码重置，否则会在所有测试中保持修改后的状态。如果某个测试不小心修改了静态共享资源，后续所有测试都会受到影响，导致测试结果不可靠，甚至出现“本地跑通CI失败”的诡异情况。IClassFixture<T>则是每个测试类一套独立的状态，测试之间互不干扰，隔离性拉满。

• 灵活性和可测试性极低：静态构造函数里的初始化逻辑很难单独测试，也没法替换依赖。比如你在静态构造函数里初始化了真实数据库连接，想换成内存数据库做单元测试几乎不可能。而IClassFixture<T>可以通过依赖注入传入，你能轻松替换fixture的实现，适配不同的测试场景，扩展性强得多。

• 资源泄漏风险：你觉得应用退出后会自动清理，但在持续集成环境或者复用进程的测试 runner 中，测试进程不会每次都重启。静态资源一直占用不释放，会导致后续测试资源不足，甚至污染测试环境。IClassFixture<T>的Dispose方法会在测试类结束后立即执行，及时释放数据库连接、文件句柄这类资源，完全没有泄漏风险。

总的来说，静态构造函数看似简单，但在测试的稳定性、可维护性上都是隐患。IClassFixture<T>是xUnit为共享状态场景设计的标准方案，能帮你避开这些坑。

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