为什么NestJS单元测试在beforeEach而非beforeAll中创建测试模块

核心设计逻辑：单元测试的隔离性要求 #

单元测试的核心准则是每个用例完全独立，执行结果不受其他用例影响，默认使用beforeEach正是为了满足这个要求，具体原因如下：

• 避免状态污染：如果将模块和服务实例的创建放在beforeAll中，所有测试用例会共用同一个实例。一旦某个用例修改了服务的内部状态（比如私有变量、缓存值、类实例属性），后续所有用例的执行结果都会被干扰，很容易出现"单条用例执行通过，批量执行失败"的玄学问题。
• 保证测试可靠性：beforeEach每次执行用例前都会初始化全新的模块和服务实例，所有用例都从完全干净的初始状态开始执行，不需要依赖用例的执行顺序，测试结果可复现性更强。

放在 beforeAll 会不会引发问题？ #

不一定，分场景：

• 如果你的服务是完全无状态的：所有方法都是纯函数，执行过程中不会修改任何实例自身的属性，也不依赖其他有状态的Provider，那么放在beforeAll不会有问题，还能小幅提升单测的运行速度。
• 如果你的服务存在状态：只要服务内部维护了运行时变量、缓存、或者依赖了其他有状态的Provider，用beforeAll就一定会出现状态污染的问题。

Nest CLI 选择beforeEach作为默认配置，是做了最普适的兼容性设计，不管你的业务代码是否有状态，都能保证测试逻辑的正确性，是保守但稳妥的最佳实践。

为什么 e2e 测试默认使用 beforeAll？ #

和单元测试的定位差异决定了配置的不同：

• e2e 测试模拟真实用户的完整操作链路，本身就允许用例之间存在状态传递（比如前一个用例模拟登录获取token，后续用例携带token请求其他接口），不需要单测级别的强隔离。
• 启动整个Nest应用的成本远高于单测创建一个小型测试模块，beforeAll只初始化一次可以大幅降低e2e测试的运行耗时。

当然如果你有特殊的e2e测试要求，需要每个用例都从全新的应用实例开始，也可以手动改成beforeEach，只是绝大多数场景下不需要这么做。

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