粗略地说，单元测试是与测试代码隔离地测试代码的一部分。想到的直接优势是：
- 运行测试变得可自动化和可重复
- 与通过 GUI 的点击式测试相比，您可以进行更精细的测试
我的问题是，目前在工具方面的“最佳实践”是什么，以及何时何地使用单元测试作为日常编码的一部分？
让我们尝试在某种程度上与语言无关并涵盖所有基础。
Rob Allen
问问题
6276 次
7 回答
14
您可能想查看三张索引卡和三张索引卡上的TDD以轻松记住测试驱动开发的本质：
卡#1。鲍勃大叔的三定律
- 除非通过失败的测试，否则不要编写生产代码。
- 只写足够的测试来证明失败。
- 只编写足以通过测试的生产代码。
卡#2：第一原则
- 快：快得让人麻木，每秒数百或数千。
- 隔离：测试清楚地隔离故障。
- 可重复：我可以重复运行它，每次都会以相同的方式通过或失败。
- 自我验证：测试明确地通过-失败。
- 及时：与微小的代码更改同步生成。
卡片 #3：TDD 的核心
- 红色：测试失败
- 绿色：测试通过
- 重构：干净的代码和测试
于 2008-08-19T22:28:56.690 回答
3
所谓的xUnit框架被广泛使用。它最初是作为 SUnit 为 Smalltalk 开发的，后来演变为 Java 的 JUnit，现在有许多其他实现，例如 .Net 的 NUnit。这几乎是一个事实上的标准——如果你说你正在使用单元测试，大多数其他开发人员会认为你的意思是 xUnit 或类似的。
于 2008-08-19T20:29:23.607 回答
3
“最佳实践”的一个很好的资源是Google 测试博客，例如最近一篇关于编写可测试代码的帖子就是一个极好的资源。特别是他们的“厕所测试”系列每周帖子非常适合在你的立方体或厕所周围张贴，所以你总是可以考虑测试。
于 2008-08-19T20:33:16.203 回答
1
xUnit 系列是单元测试的中流砥柱。它们被集成到 Netbeans、Eclipse 和许多其他 IDE 中。它们为单元测试提供了一个简单、结构化的解决方案。
我在编写测试时总是尝试做的一件事是尽量减少外部代码的使用。我的意思是：我尽量减少测试的设置和拆卸代码，并尽量避免使用其他模块/代码块。编写良好的模块化代码在设置和拆卸时不应该需要太多的外部代码。
于 2008-08-19T20:27:34.670 回答
0
NUnit 是适用于任何 .NET 语言的好工具。
单元测试可以通过多种方式使用：
- 测试逻辑
- 增加代码单元的分离。如果你不能完全测试一个函数或一段代码，那么组成它的部分就太相互依赖了。
- 驱动开发，有些人在编写要测试的代码之前先编写测试。这迫使你思考你想让代码做什么，然后给你一个明确的指导方针，告诉你什么时候实现了。
于 2008-08-19T20:44:56.400 回答
0
不要忘记重构支持。.NET 上的 ReSharper 为丢失的代码提供自动重构和快速修复。这意味着，如果您编写对不存在的东西的调用，ReSharper 会询问您是否要创建缺失的部分。
于 2008-08-27T21:00:32.047 回答