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