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

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

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

解决方案

回答

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

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

回答

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

回答

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

回答

好吧，这里有一些最佳实践，来自那些没有进行尽可能多的单元测试的人……咳嗽。

• 确保测试仅测试一件事和一件事。
• 随时编写单元测试。最好在编写要测试的代码之前。
• 不要对GUI进行单元测试。
• 分开关注点。
• 最小化测试的依赖性。
• 用模拟嘲笑行为。

回答

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

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

• 测试逻辑
• 增加代码单元的间隔。如果我们不能完全测试功能或者代码部分，则组成它的各部分之间是相互依存的。
• 驱动开发，有些人在编写要测试的代码之前先编写测试。这迫使我们考虑要执行的代码，然后为我们确定何时实现此目标提供明确的指导。

回答

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

卡＃1. 鲍伯叔叔三定律

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

卡＃2：第一原则

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

卡＃3：TDD的核心

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

回答

不要忘记重构支持。 .NET上的ReSharper提供了自动重构功能，可以快速修复丢失的代码。这意味着，如果我们对不存在的内容进行调用，ReSharper将询问我们是否要创建丢失的片段。