【发布时间】：2008-08-19 20:18:09
【问题描述】：
粗略地说，单元测试是与测试代码隔离地测试代码的一部分。想到的直接优势是：
- 运行测试变得可自动化且可重复
- 与通过 GUI 的点击式测试相比，您可以进行更精细的测试
我的问题是，目前在工具方面的“最佳实践”是什么，以及何时何地使用单元测试作为日常编码的一部分？
让我们尝试在某种程度上与语言无关并涵盖所有基础。
【问题讨论】：
标签： unit-testing
【发布时间】：2008-08-19 20:18:09
【问题描述】：
好的，这里有一些最佳实践，来自一些没有尽可能多地进行单元测试的人……咳咳。
- 确保您的测试通过one 一件事，只有一件事。
- 随时编写单元测试。最好是 before 您编写要测试的代码。
- 不要对 GUI 进行单元测试。
- Separate your concerns。
- 尽量减少测试的依赖性。
- 使用mocks 模拟行为。
【讨论】：
-
嗨，John，您能详细说明您为什么不对 GUI 进行单元测试吗？
-
是的，请详细说明您不应该测试 GUI 的原因。
-
您是否在 GUI 上运行不同行为类型的测试？
您可能想查看TDD on Three Index Cards 和Three Index Cards to Easily Remember the Essence of Test-Driven Development：
卡#1。鲍勃大叔的三定律
- 除非通过失败的测试，否则不要编写生产代码。
- 仅编写足以证明失败的测试。
- 只需编写足以通过测试的生产代码。
卡片#2：第一原则
- 快速：快得令人麻木，每秒数百或数千。
- 已隔离：测试清楚地隔离了故障。
- 可重复：我可以重复运行它，每次都会以相同的方式通过或失败。
- 自我验证：测试明确通过失败。
- 及时：与微小的代码更改同步生成。
卡 #3：TDD 的核心
- 红色：测试失败
- 绿色：测试通过
- 重构：干净的代码和测试
【讨论】：
所谓的xUnit框架被广泛使用。它最初是作为 SUnit 为 Smalltalk 开发的，后来演变为 Java 的 JUnit，现在有许多其他的实现，例如 .Net 的 NUnit。这几乎是一个事实上的标准——如果你说你正在使用单元测试，大多数其他开发人员会认为你的意思是 xUnit 或类似的。
【讨论】：
“最佳实践”的一个很好的资源是Google Testing Blog，例如最近在Writing Testable Code 上的帖子就是一个很棒的资源。特别是他们的“厕所测试”系列每周帖子非常适合在你的立方体或厕所周围张贴，所以你总是可以考虑测试。
【讨论】：
xUnit 系列是单元测试的支柱。它们被集成到 Netbeans、Eclipse 和许多其他 IDE 中。它们为单元测试提供了一个简单、结构化的解决方案。
我在编写测试时总是尝试做的一件事是尽量减少外部代码的使用。我的意思是：我尽量减少测试的设置和拆卸代码，并尽量避免使用其他模块/代码块。编写良好的模块化代码在设置和拆卸时不应该需要太多的外部代码。
【讨论】：
NUnit 是适用于任何 .NET 语言的好工具。
可以通过多种方式使用单元测试：
- 测试逻辑
- 增加代码单元的分隔。如果你不能完全测试一个函数或一段代码，那么组成它的部分就太相互依赖了。
- 驱动开发，有些人在编写要测试的代码之前编写测试。这会迫使您思考您希望代码做什么，然后为您提供一个明确的指导方针，告诉您何时实现。
【讨论】：
不要忘记重构支持。 .NET 上的 ReSharper 为丢失的代码提供自动重构和快速修复。这意味着，如果您对不存在的内容编写调用，ReSharper 会询问您是否要创建缺失的部分。
【讨论】：