问TDD中测试单元的效率

EN

这并不是TDD的亮点--请记住，TDD的动机不是测试(尽管这是一个很好的副作用)，而是设计，也就是说，使代码易于更改。

TDD仪式的一部分是在开发周期中频繁地运行测试；偏离开发流程的测试(例如，需要很长时间运行)是越界的。这并不是说您不能进行这些测试；支持TDD的一个论点是，它确保您有可测试的代码。但你通常不会期望在红色/绿色/循环仪式上运行需要大量挂钟时间的测试。

此外，当实现不稳定时，与实现紧密耦合的测试是真正的阻力。当测试干扰更改代码中封装的设计时，您就失去了可信度。

有时，您可以引入一个可观察性要求，这样您就可以从系统外部获得一个关键部分被调用的频率。只要该关键部分被系统使用，那么也许您就可以使用计数作为证据，并估计实现是否按照您预期的方式扩展。

在排序的情况下，这可能意味着比较函数是一个可配置的依赖项的设计，而在测试中，我们提供了一个计算调用频率的实现。

但这确实引入了一些耦合--在这一点上，你要衡量的是你的方法是否被调用，而不是测试对象是否产生正确的答案。在某些情况下，这很好。在其他情况下，这是过度耦合。我不知道有任何简单的启发，你可以用它来区分这两种情况，而不用尝试实验，当过度耦合发生时会被烧焦。

与TDD不同，您可以使用test-after：

• 注入一个计数器，以测量操作数。
• 运行给定输入的算法
• 确认计数小于阈值。

这将防止操作次数的倒退。(请记住，这并不能保证现实世界的表现。)