使用 时TestBed，您真的是在对组件进行单元测试还是在进行集成测试？
创建一个夹具（TestBed.createComponent(AppComponent)）并fixture.detectChanges()自动调用调用ngOnInit。如果您想测试另一种方法，您现在正在测试多个单元。
这就引出了另一个问题：您应该测试单元，还是测试用户操作？例如，您是否应该测试该方法setDimensions，或者您是否应该测试当用户单击某个按钮时，元素是否具有适当的尺寸等。
我猜第一种测试方式会更接近“单元测试”方式，但是你仍然必须处理被调用组件的生命周期方法。这让我觉得没有办法使用TestBed. 存根所有生命周期方法似乎很荒谬。
无论您决定测试哪种方式，都应该测试 DOM，不是吗？然后，您不会通过包含 DOM api 进行孤立测试。
引用自Angular 文档：
与 Angular 应用程序的所有其他部分不同，组件结合了 HTML 模板和 TypeScript 类。组件确实是模板和类一起工作。为了充分测试一个组件，您应该测试它们是否按预期协同工作。
此类测试需要像 Angular 一样在浏览器 DOM 中创建组件的宿主元素，并按照其模板的描述调查组件类与 DOM 的交互。
正如您将在下面的部分中看到的那样，Angular TestBed 促进了这种测试。但在许多情况下，单独测试组件类而不涉及 DOM，可以以更简单、更明显的方式验证组件的大部分行为。
所以在这里，单元是一个组件（模板和类一起工作）。您应该尝试通过存根输入和依赖项来测试组件。
我想如果您从上到下阅读测试文档一次，您就会在其中找到问题的答案。
以下是从测试驱动开发维基百科页面收集的更多信息。
对于 TDD，一个单元最常被定义为一个类，或一组通常称为模块的相关功能。据称，保持相对较小的单位可以提供关键的好处 [...]
所以单元测试不一定测试最小的单元。
由于大量使用单元测试，测试驱动开发在需要完整功能测试来确定成功或失败的情况下无法执行足够的测试。 [21] 这些示例包括用户界面、与数据库一起使用的程序，以及一些依赖于特定网络配置的程序。TDD 鼓励开发人员将最少数量的代码放入此类模块中，并最大化可测试库代码中的逻辑，使用假货和模拟来表示外部世界。 [22]
UI 可以通过单元测试进行测试，直到某个收益递减点，此时功能测试/e2e 测试很有用。
单元测试之所以如此命名，是因为它们每个测试一个代码单元。一个复杂的模块可能有一千个单元测试，而一个简单的模块可能只有十个。用于 TDD 的单元测试不应该跨越程序中的进程边界，更不用说网络连接了。这样做会引入延迟，使测试运行缓慢并阻止开发人员运行整个套件。引入对外部模块或数据的依赖也会将单元测试变成集成测试。如果一个模块在一系列相互关联的模块中出现异常行为，那么在哪里寻找故障原因就不是那么清楚了。
我想我现在将集成测试定义为同时测试应用程序外部部分的测试，例如数据库或服务器 API 等其他进程。