单元测试入门

Question

粗略地说，单元测试是与测试代码隔离地测试代码的各个部分。我想到的直接优势是：

• 运行测试变得可自动化且可重复
• 与通过 GUI 进行点击式测试相比，您可以进行更精细的测试

梨属

我的问题是，当前在工具方面的“最佳实践”是什么，以及何时何地使用单元测试作为日常编码的一部分？

让我们尝试在某种程度上与语言无关并涵盖所有基础。

Answer 1

好吧，这里有一些最佳实践，来自某个没有进行足够多单元测试的人……咳。

1. 确保你的测试经过测试 一一件事，而且只有一件事。
2. 边写边写单元测试。最好是 前 您编写要测试的代码。
3. 不要对 GUI 进行单元测试。
4. 分开您的担忧.
5. 最小化测试的依赖性。
6. 模拟行为 嘲笑.

Answer 2

您可能想看看 三张索引卡上的 TDD 和 三张索引卡可轻松记住测试驱动开发的本质:

卡#1。鲍勃叔叔的三定律

• 除了通过失败的测试之外，不要编写任何生产代码。
• 仅编写足以证明失败的测试。
• 仅编写足以通过测试的生产代码。

卡#2：第一原则

• 快速地：速度快得令人麻木，每秒数百或数千。
• 孤立：该测试清楚地隔离了故障。
• 可重复：我可以重复运行它，每次都会以相同的方式通过或失败。
• 自验证：测试的结果是明确的“通过”-“未通过”。
• 及时：通过微小的代码更改以同步方式生成。

卡#3：TDD的核心

• 红色的：测试失败
• 绿色的：测试通过
• 重构：干净的代码和测试

Answer 3

所谓的 x单位 框架被广泛使用。它最初是为 Smalltalk 开发的 SUnit，后来演变为 JUnit for Java，现在有许多其他实现，例如 NUnit for .Net。这几乎是事实上的标准 - 如果您说您正在使用单元测试，大多数其他开发人员会假设您指的是 xUnit 或类似的。

Answer 4

“最佳实践”的一个重要资源是 谷歌测试博客, ，例如最近的一篇文章 编写可测试的代码 是一个很棒的资源。具体来说，他们的“厕所测试”系列每周帖子非常适合在您的隔间或厕所周围张贴，因此您可以随时考虑测试。

Answer 5

xUnit 系列是单元测试的支柱。它们被集成到 Netbeans、Eclipse 和许多其他 IDE 中。他们为单元测试提供了简单、结构化的解决方案。

在编写测试时我总是尝试做的一件事是尽量减少外部代码的使用。我的意思是：我尝试尽可能减少测试的设置和拆卸代码，并尽可能避免使用其他模块/代码块。编写良好的模块化代码在设置和拆卸中不应需要太多外部代码。

Answer 6

NUnit 对于任何 .NET 语言来说都是一个很好的工具。

单元测试可以通过多种方式使用：

1. 测试逻辑
2. 增加代码单元的分离。如果您无法完全测试某个函数或一段代码，那么组成它的各个部分就太相互依赖了。
3. 推动开发，有人编写测试 前 他们编写要测试的代码。这迫使你思考你想要代码做什么 做, ，然后为您提供明确的指导方针，告诉您何时实现这一目标。

Answer 7

不要忘记重构支持。.NET 上的 ReSharper 提供自动重构和快速修复丢失的代码。这意味着如果您编写对不存在的内容的调用，ReSharper 会询问您是否要创建缺失的部分。