对于经典的组件单元测试，我们如何将其迁移到Glimmer？这个组件单元测试正在测试一个没有暴露给用户的本地道具。
const component = this.owner .factoryFor('component:some-component') .create({ someModel: { foo: 'bar' } }); assert.equal(component.get('someLocalProp'), false);
vohkndzv1#
这些确实是一个反模式！实际上，单元测试组件通常是一个反模式：你实际上并不是这个组件的testing the interface。我的意思是这样的：与组件的所有交互，无论是作为另一个开发者调用它还是作为一个用户与它交互，都是通过模板发生的。像这样测试它的“单元”并不代表最终用户或调用它的其他开发者将如何能够与它交互。大多数时候，这样的测试之所以存在，是因为开发人员想要检查内部方法或getter的行为。然而，这与我们在测试时应该做的事情完全 * 相反 *。我们 * 只 * 想要测试公共契约：这就是我们真正进行重构的原因：也就是说，改变内部实现而不改变公共契约。依赖于内部行为的测试必然是过耦合和脆弱的。对于UI组件，这意味着像这样的“单元”测试实际上总是过耦合和脆弱的。例如，如果getter在模板中是不可见的，那么谁会关心它是否计算给定的值呢？我们实际上只关心计算的 * 结果 *。Glimmer组件没有直接对应的API，部分原因就是这个。这里正确的模式是将组件测试重写为集成测试，它 * 确实 * 允许您测试组件的实际接口（或者如果它不提供实际值，则删除它）。
1条答案
按热度按时间vohkndzv1#
这些确实是一个反模式！实际上，单元测试组件通常是一个反模式：你实际上并不是这个组件的testing the interface。我的意思是这样的：与组件的所有交互，无论是作为另一个开发者调用它还是作为一个用户与它交互，都是通过模板发生的。像这样测试它的“单元”并不代表最终用户或调用它的其他开发者将如何能够与它交互。
大多数时候，这样的测试之所以存在，是因为开发人员想要检查内部方法或getter的行为。然而，这与我们在测试时应该做的事情完全 * 相反 *。我们 * 只 * 想要测试公共契约：这就是我们真正进行重构的原因：也就是说，改变内部实现而不改变公共契约。依赖于内部行为的测试必然是过耦合和脆弱的。对于UI组件，这意味着像这样的“单元”测试实际上总是过耦合和脆弱的。
例如，如果getter在模板中是不可见的，那么谁会关心它是否计算给定的值呢？我们实际上只关心计算的 * 结果 *。
Glimmer组件没有直接对应的API，部分原因就是这个。这里正确的模式是将组件测试重写为集成测试，它 * 确实 * 允许您测试组件的实际接口（或者如果它不提供实际值，则删除它）。