测试消耗其他组件的组件时，关注点分离是什么？

如果您希望最大程度地覆盖代码，或者将父组件和子组件集成在一起是至关重要的（即，如果它没有以正确的方式将某些东西交给子组件，那么事情可能会进行得很顺利）错误），那么您绝对应该测试父组件和子组件之间的多种可能配置。

我理解您说的不是很干（在某些形式或情况下确实不是很干）的意思，但是您应该这样考虑：

在那里你隔离子组件和测试各种配置的情况下，是你的测试应主要关注测试什么这些组件与配置做的，当涉及到DOM或与任何服务测试的界限，等等。

以您的示例为例，如果我有一个<Image>组件，当我给它特定的道具或选项时，我将编写集成测试以断言其行为。例如，如果我传入这些参数会怎样？

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

集成测试应该测试这些值对其渲染的内容以及用户与图像的交互方式是否有影响。也许width并以百分比height设置<img>标签的宽度和高度，然后单击图像应调用提供给该组件的操作。

另一方面，如果我已经有一个集成测试可以测试该组件可以执行的所有操作，那么为什么我们需要测试<Carousel />该<Image />组件是否可以渲染该组件<Image />？

答案是测试这两个组件之间的集成，并确保父组件与子组件正确连接。换句话说，就是要确保正确地<Carousel />将所有选项传递给其子组件。

在某些情况下，这可能没什么大不了的，实际上，我认为很多时候这里的测试都可以忽略，但是就像我之前说的那样，如果集成很关键，则必须测试父级如何传递选项给孩子们。

为了说明这是如何提供覆盖的，请说我将<Carousel />组件的模板连接起来，如下所示：

轮播

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

看到这一点，您可以清楚地看到发生了什么-我的意思是将该动作链接为@onClick，而不是@onChange。但是我所有的集成测试<Image />都通过了，因此如果不测试<Carousel />组件如何将属性传递给子级，我将缺乏覆盖范围，并且此错误更有可能将其投入生产。

使其不进行DRY的部分是针对父级进行集成测试，并且必须编写非常相似的代码（即，确保单击图像时它调用正确的动作）。有时，这样做并没有真正好的方法-而且我认为在这种情况下，集成可能会被忽略。在其他时候，可以采取一些措施来减少重复的测试代码。

在Ember中，有时传入属性会与子组件的特定类名绑定（除了其他功能）。我们可以编写一个集成测试来检查“子组件是否收到正确的属性？”，而不是复制一个检查“子组件的行为是否正确？”的测试。

例如，如果我们的父组件是这样连接的：

轮播

<Image @someFlag=true />

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

• 向图像添加一个类
• 使图像在鼠标悬停时尺寸增大
• 发出网络请求，以在单击图像时报告一些用户指标

<Image />如果@someFlag为真，则组件的集成测试将测试所有这些内容。但是，除了重复该精确测试之外，我们<Carousel />组件的集成测试可以简单地检查：“<Image />组件是否具有预期的类名？” 这实际上是减少您需要编写的重复测试代码数量的一种非常常见的方法。

当然，在某些情况下，您不需要测试集成。如果<Carousel />只是将它收到的任何东西传递给子代，那么您就有理由反对为这种事情编写集成测试。