比方说，我们需要一个排序功能，并希望确保它是在O(nlogn)而非O(n^2)中实现的。
使用测试驱动的开发，是否有系统的方法来测试此功能的执行效率？
根据Wikipedia，测试实现细节被认为是测试驱动开发中的反模式，这是否可以防止TDD尝试检查满足要求的代码效率？还是有系统的方法来做到这一点？
答案 0 :(得分：1)
这并不是TDD的真正优势-请记住，TDD的动机不是测试（尽管这是一个很好的副作用），而是 design ，也就是说，代码易于更改。
TDD仪式的一部分是在开发周期中频繁运行测试；干扰开发流程的测试（例如，花费很长时间运行）超出了范围。这并不是说您无法进行这些测试；支持TDD的理由之一是，它确保您拥有可测试的代码。但是您通常不会期望在红色/绿色/回收仪式期间运行需要大量挂钟时间的测试。
此外，当实现不稳定时，紧密耦合到实现的测试是真正的障碍。当测试干扰更改代码中的封装设计时，您将失去信誉。
有时，您可以引入可观察性的要求，以便从系统外部可以了解关键部分被调用的频率。并且只要系统正在使用该关键部分，那么您就可以将计数用作证据，并估计实现是否按您期望的方式扩展。
在排序的情况下，这可能意味着比较功能是可配置的依赖项的设计，并且在测试中，我们提供了一个计算调用频率的实现。
但这确实引入了一些耦合-此时，您要测量的是是否调用了您的方法，不是是测试对象是否给出了正确答案。在某些情况下，这很好。在其他情况下，这是过度耦合。我不知道有任何简单的启发式方法可用于区分这两种情况，而无需尝试实验，也不会在发生过度耦合时感到烦躁。
答案 1 :(得分：0)
您可以使用test-after代替TDD：
这将防止操作数量的下降。 （请记住，这并不能保证实际性能。）