单元测试入门

Unit testing is, roughly speaking, testing bits of your code in isolation with test code. The immediate advantages that come to mind are:

• Running the tests becomes automate-able and repeatable
• You can test at a much more granular level than point-and-click testing via a GUI

Rytmis

我的问题是，就工具而言，当前的"最佳实践"是什么？在日常编码中何时何地使用单元测试？

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

好吧，这里有一些最佳实践，他们没有进行应有的单元测试……咳嗽。

您可能需要查看三张索引卡和三张索引卡上的TDD，以轻松记住测试驱动开发的本质：

卡＃1。鲍伯叔叔的三定律

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

卡＃2：第一原则

• 快速：头脑麻木，每秒数百或数千。
• 隔离：测试可以清楚地隔离故障。
• 可重复：我可以重复运行它，并且每次都会以相同的方式通过或失败。
• 自验证：测试明确通过失败。
• 及时：通过微小的代码更改就可以同步生成。

卡＃3：TDD的核心

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

Google测试博客是"最佳做法"的一个很好的资源，例如，最近发表的有关编写可测试代码的文章是一个很棒的资源。特别是他们的"厕所测试"系列每周帖子非常适合在您的立方体或厕所周围发布，因此您始终可以考虑进行测试。

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

xUnit系列是单元测试的支柱。它们已集成到Netbeans，Eclipse和许多其他IDE之类的产品中。他们为单元测试提供了一种简单的结构化解决方案。

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

不要忘记重构支持。 .NET上的ReSharper提供了自动重构功能，可以快速修复丢失的代码。这意味着如果您写一个不存在的东西的电话，ReSharper将会询问您是否要创建丢失的部分。

NUnit是任何.NET语言的好工具。

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