如果您的目标是尽可能实现最高的代码覆盖率，或者父组件和子组件的集成至关重要（即，如果不能以正确的方式将某些内容传递给子组件，那么事情可能会非常错误），那么您绝对应该测试父组件和子组件之间的多种可能的配置。
我明白你说它感觉不太干（在某些情况下，它真的不干）是什么意思，但你应该这样想：
在隔离子组件并测试各种配置的情况下，您的测试应该主要关注测试这些组件在DOM中对配置做了什么，或者测试与任何服务的边界，等等。
举个例子，如果我有一个<Image>组件，我将编写集成测试来Assert它的行为，当我给予它特定的属性或选项时。例如，如果我传入这些参数会发生什么？

<Image @width=100 @height=100 @onClick={{action "doSomething"}} />

集成测试应该测试这些值对呈现的内容以及用户与图像的交互方式是否有影响。也许width和height以百分比的形式设置<img>标记的宽度和高度，并且单击图像应该调用提供给该组件的操作。
另一方面，如果我已经有一个集成测试来测试<Image />组件所能做的一切，为什么还需要测试<Carousel />组件是否可以呈现<Image />组件呢？
答案是测试这两个组件之间的集成，并确保父组件与子组件正确连接，换句话说，就是确保<Carousel />正确地将所有选项传递给其子组件。
在某些情况下，这可能不是什么大问题，实际上，我认为这里的很多时间测试都可以忽略，但就像我前面所说的，如果集成是关键的，那么你必须测试父级是如何将选项传递给子级的。
为了说明这是如何提供覆盖率的，假设我将<Carousel />组件的模板连接起来，如下所示：

传送带.hbs

<Image @width=50 @height=50 @onChange={{action "doSomething"}} />

通过这个例子，你可以清楚地看到发生了什么--我的意思是把这个动作连接成@onClick，而不是@onChange。然而，我对<Image />的所有集成测试都通过了，所以如果不测试<Carousel />组件如何将属性传递给其子组件，我将缺少覆盖率，这个bug有更大的机会进入生产。
使它不干的部分是查看父级的集成测试，并且必须编写非常相似的代码（即，确保当我单击图像时它调用正确的操作）。有时候没有真实的好的方法来实现这一点--我认为这类场景可能会忽略集成。其他时候，可以做一些事情来减少重复测试代码的数量。
在Ember中，有时传入的属性与子组件的特定类名绑定（以及其他功能）。与其重复一个检查“子组件的行为是否正确？"的测试，我们可以编写一个检查“子组件是否收到了正确的属性？”的集成测试。
例如，如果我们的父组件是这样连接的：

传送带.hbs

<Image @someFlag=true />

假设此@someFlag属性执行以下操作：

• 将类添加到图像
• 使图像在鼠标悬停时放大
• 发出网络请求，以在单击图像时报告某些用户指标

当@someFlag为true时，<Image />组件的集成测试将测试所有这些内容。但是，<Carousel />组件的集成测试可以简单地检查：“<Image />组件是否具有预期的类名？”这实际上是减少需要编写的重复测试代码量的一种非常常用的方法。
当然，在有些情况下，你不需要测试集成。如果<Carousel />只是把它接收到的任何东西传递给它的孩子，那么你就有理由反对为这类事情编写集成测试。