测试单元在 TDD 中的效率
Testing Unit's Efficiency in TDD
假设我们需要一个排序函数，并希望确保它在 O(nlogn) 而不是 O(n^2) 中实现。
使用测试驱动开发，有没有系统的方法来测试这个功能的执行效率？
根据 Wikipedia，测试实现细节 被认为是测试驱动开发中的反模式，这是否会阻止 TDD 尝试检查满足要求的代码？或者是否有系统的方法来做到这一点？
这并不是 TDD 的真正优势——请记住，TDD 的动机不是测试（尽管这是一个很好的副作用），而是 设计，它就是说让代码容易改。
TDD 仪式的一部分是 运行在开发周期中经常进行测试；分散开发流程注意力的测试（例如，花很长时间 运行）是禁止的。这并不是说您不能进行这些测试。支持 TDD 的论点之一是它确保您拥有可测试的代码。但是您通常不会期望在 red/green/recycle 仪式期间进行需要大量挂钟时间的 运行 测试。
此外，当实现不稳定时，与实现紧密耦合的测试是真正的拖累。当测试干扰更改代码中的封装设计时，您将失去可信度。
有时，您可以引入可观察性要求，以便您可以从系统外部了解调用关键部分的频率。只要系统正在使用该关键部分，那么也许您可以使用计数作为证据，并估计实施是否按您预期的方式扩展。
在排序的情况下，这可能意味着比较函数是可配置依赖项的设计，并且在测试中我们提供了一个计算它被调用频率的实现。
但这确实引入了一些耦合——此时您要衡量的是您的方法是否被调用，而不是测试对象是否产生了正确的答案.在某些情况下，这很好。在其他情况下，这是过度耦合。我不知道有什么简单的启发式方法可以用来区分这两种情况，而无需尝试实验并在发生过度耦合时被烧毁。
您可以使用 test-after 代替 TDD：
- 注入一个测量操作次数的计数器
- 运行 给定输入的算法
- 确认计数小于阈值
这将防止操作数量下降。 （请记住，它不能保证实际性能。）
假设我们需要一个排序函数，并希望确保它在 O(nlogn) 而不是 O(n^2) 中实现。
使用测试驱动开发，有没有系统的方法来测试这个功能的执行效率？
根据 Wikipedia，测试实现细节 被认为是测试驱动开发中的反模式，这是否会阻止 TDD 尝试检查满足要求的代码？或者是否有系统的方法来做到这一点？
这并不是 TDD 的真正优势——请记住，TDD 的动机不是测试（尽管这是一个很好的副作用），而是 设计，它就是说让代码容易改。
TDD 仪式的一部分是 运行在开发周期中经常进行测试；分散开发流程注意力的测试（例如，花很长时间 运行）是禁止的。这并不是说您不能进行这些测试。支持 TDD 的论点之一是它确保您拥有可测试的代码。但是您通常不会期望在 red/green/recycle 仪式期间进行需要大量挂钟时间的 运行 测试。
此外，当实现不稳定时，与实现紧密耦合的测试是真正的拖累。当测试干扰更改代码中的封装设计时，您将失去可信度。
有时，您可以引入可观察性要求，以便您可以从系统外部了解调用关键部分的频率。只要系统正在使用该关键部分，那么也许您可以使用计数作为证据，并估计实施是否按您预期的方式扩展。
在排序的情况下，这可能意味着比较函数是可配置依赖项的设计，并且在测试中我们提供了一个计算它被调用频率的实现。
但这确实引入了一些耦合——此时您要衡量的是您的方法是否被调用，而不是测试对象是否产生了正确的答案.在某些情况下，这很好。在其他情况下，这是过度耦合。我不知道有什么简单的启发式方法可以用来区分这两种情况，而无需尝试实验并在发生过度耦合时被烧毁。
您可以使用 test-after 代替 TDD：
- 注入一个测量操作次数的计数器
- 运行 给定输入的算法
- 确认计数小于阈值
这将防止操作数量下降。 （请记住，它不能保证实际性能。）