blocks|key|1339291|text|这并不是TDD的亮点--请记住，TDD的动机不是测试(尽管这是一个很好的副作用)，而是设计，也就是说，使代码易于更改。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1339292|TDD仪式的一部分是在开发周期中频繁地运行测试；偏离开发流程的测试(例如，需要很长时间运行)是越界的。这并不是说您不能进行这些测试；支持TDD的一个论点是，它确保您有可测试的代码。但你通常不会期望在红色/绿色/循环仪式上运行需要大量挂钟时间的测试。|1339293|此外，当实现不稳定时，与实现紧密耦合的测试是真正的阻力。当测试干扰更改代码中封装的设计时，您就失去了可信度。|1339294|有时，您可以引入一个可观察性要求，这样您就可以从系统外部获得一个关键部分被调用的频率。只要该关键部分被系统使用，那么也许您就可以使用计数作为证据，并估计实现是否按照您预期的方式扩展。|1339295|在排序的情况下，这可能意味着比较函数是一个可配置的依赖项的设计，而在测试中，我们提供了一个计算调用频率的实现。|1339296|但这确实引入了一些耦合--在这一点上，你要衡量的是你的方法是否被调用，而不是测试对象是否产生正确的答案。在某些情况下，这很好。在其他情况下，这是过度耦合。我不知道有任何简单的启发，你可以用它来区分这两种情况，而不用尝试实验，当过度耦合发生时会被烧焦。|1339297|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|P|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Q|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

It's not really the sweet spot of TDD -- keep in mind that the motivation for TDD is not testing (although that is a nice side effect), but design, which is to say making the code easy to change.

Part of the TDD ritual is running tests frequently during the development cycle; tests that distract from the development flow (for example, by taking a long time to run) are out of bounds. That's not to say that you can't have those tests; one of the arguments in favor of TDD is that it ensures that you have testable code. But you wouldn't normally be expecting to run tests that require significant wall clock time during the red/green/recycle ritual.

Furthermore, tests that are tightly coupled to an implementation are a real drag when the implementation is unstable. You lose credibility when the tests interfere with changing the encapsulated design in the code.

Sometimes, you can introduce an observability requirement, so that from outside the system you can get a count of how often a critical section is invoked. And as long as that critical section is being used by the system, then maybe you can use the counts as evidence, and estimate whether or not the implementation scales the way you expect.

In the case of sort, that might mean a design where the comparison function is a configurable dependency, and in the test we provide an implementation that counts how often it is invoked.

But that does introduce some coupling -- at that point what you are measuring is whether or not your method is invoked, not whether or not the test subject produces the right answer. In some cases, that's fine. In other cases, that's over coupling. I don't know of any simple heuristic that you can use to distinguish the two cases without trying the experiment and getting burned when the over coupling happens.

blocks|key|708718|text|与TDD不同，您可以使用test-after：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|708719|注入一个计数器，以测量操作数。|unordered-list-item|708720|运行给定输入的算法|708721|确认计数小于阈值。|708722|这将防止操作次数的倒退。(请记住，这并不能保证现实世界的表现。)|708723|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|O|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|P|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|Q|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|L|$]]

Instead of TDD, you can use test-after:

<ul>
<li>Inject a counter that measures number of operations</li>
<li>Run the algorithm for given input</li>
<li>Confirm that the count is less than a threshold</li>
</ul>

This would prevent regressions in the number of operations. (Keep in mind that it's no guarantee of real-world performance.)

Let's say we need a sort function and want to ensure that it is implemented in <code>O(nlogn)</code> rather than <code>O(n^2)</code>.

Using test driven development, is there a systematic way to test the efficiency of implementation of this function? 

According to <a href="https://en.wikipedia.org/wiki/Test-driven_development" rel="nofollow noreferrer">Wikipedia</a>, Testing implementation details is considered an anti-pattern in Test Driven Development, does this prevent TDD from any attempt to check the efficiency of the code satisfying a requirement? Or is there a systematic way for doing so?

Testing Unit's Efficiency in TDD

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

假设我们需要一个排序函数，并希望确保它是用O(nlogn)而不是O(n^2)实现的。使用测试驱动开发，是否有一种系统的方法来测试该功能的实现效率？根据，测试实现细节被认为是测试驱动开发中的一种反模式，这是否阻止了TDD检查满足需求的代码的效率？还是有系统的方法来做到这一点？

问TDD中测试单元的效率
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问TDD中测试单元的效率EN