使用TestBed测试Angular 6组件：是单元测试还是集成测试？

这个问题确实戳中了Angular测试里最容易让人困惑的点，我结合自己的实践来拆解下：

1. 用TestBed时，到底是单元测试还是集成测试？ #

严格意义上，当你用TestBed.createComponent(AppComponent)并调用fixture.detectChanges()触发ngOnInit时，这已经属于轻量集成测试了。因为TestBed默认帮你搭建了组件的运行环境：它会编译组件模板、处理依赖注入、触发生命周期钩子，相当于把组件类、模板、Angular的渲染机制整合在一起测试了。

如果是纯粹的单元测试，你根本不需要TestBed——直接实例化组件类就行：

const component = new AppComponent(/* 手动传入依赖的mock */);

这种方式下，生命周期钩子不会自动触发，也不会涉及DOM，完全只测试组件类本身的逻辑。

2. 该测试单元方法，还是用户行为？ #

这取决于你的测试目标：

• 测单元方法（比如setDimensions）：这更贴近“纯单元测试”的范畴，适合验证某个核心逻辑的正确性（比如计算尺寸的算法是否正确）。这种测试速度快、隔离性强，能快速定位方法内部的bug。
• 测用户行为（比如点击按钮后元素尺寸变化）：这属于行为驱动的集成测试，模拟的是真实用户的操作场景。这种测试能验证组件整体的交互是否符合预期——比如按钮点击事件是否绑定正确、模板渲染是否和组件逻辑同步，能发现单元测试覆盖不到的“类+模板”联动bug。

两种测试都有价值，不用非选其一，而是根据组件的复杂度和测试需求搭配使用。

3. 能用TestBed做单元测试吗？桩化生命周期很荒谬？ #

其实没必要硬用TestBed做纯单元测试——因为TestBed的设计初衷就是为了集成测试。如果非要用，你可以通过配置TestBed来尽可能隔离：比如用providers替换所有依赖为mock，甚至用overrideComponent禁用模板，但这样做反而比直接new组件更麻烦。

桩化所有生命周期钩子确实很荒谬，因为如果是纯单元测试，你完全可以手动控制：比如需要测ngOnInit里的逻辑，直接调用component.ngOnInit()就行，根本不需要TestBed触发。

4. 测试DOM就不是孤立测试了？ #

没错，一旦涉及DOM，测试就不再是完全孤立的——你会依赖Angular的渲染引擎、浏览器的DOM API。但这不是缺点，反而很有必要：真实用户就是通过DOM和组件交互的，这种测试能帮你发现模板绑定错误、事件处理失效、样式渲染异常等单元测试覆盖不到的问题。

如果追求完全孤立，那就只测组件类里的纯逻辑方法，不要碰DOM；如果要验证组件的实际表现，测试DOM是必不可少的。

内容的提问来源于stack exchange，提问作者Maxime Dupré