问如何写出好的单元测验？

EN

重要的一点(我一开始没有意识到)是，单元测试是一种可以自己使用的测试技术，而不需要应用完整的测试驱动方法。

例如，您需要通过向问题区域添加单元测试来改进遗留应用程序，或者希望在现有应用程序中查找bug。现在编写一个单元测试来公开问题代码，然后修复它。这些都是半测试驱动的，但可以完全适应您当前(非TDD)的开发过程。

我发现有两本书是有用的：

微软.NET中的测试驱动开发

一只手看看测试驱动的开发，以下是肯特·贝克最初的TDD书。

基于C#和nUnit的实用单元测试

它直接到了什么是单元测试，以及如何应用它。

针对你们的观点：

1. 在实际条件下，单元测试是类中的一个方法，它包含足够的代码来测试应用程序的一个方面/行为。因此，您通常会有许多非常简单的单元测试，每个测试都是应用程序代码的一小部分。例如，在nUnit中，您创建一个包含任意数量的测试方法的TestFixture类。关键是测试“测试代码的一个单元”(最小的(合理的)单元)。您不需要测试所使用的底层API，只需要测试您编写的代码。
2. 有些框架可以从创建测试类中提取一些繁重的工作，但是我不推荐它们。要创建实际为重构提供安全网的有用的单元测试，除了让开发人员考虑测试代码的内容和方法之外，别无选择。如果您开始依赖于生成单元测试，那么很容易将它们看作是必须完成的另一项任务。如果你发现自己处在这种情况下，你就完全错了。
3. 对于每个类、每个方法有多少个单元测试，没有简单的规则。您需要查看应用程序代码，并对复杂性存在的地方进行有知识的评估，并为这些领域编写更多的测试。大多数人从测试公共方法开始，只是因为这些方法通常会执行其余的私有方法。然而，情况并不总是如此，有时需要测试私有方法。

简而言之，即使是经验丰富的单元测试人员也从编写明显的单元测试开始，然后寻找更加微妙的测试，一旦他们编写了明显的测试，这些测试就会变得更加清晰。他们并不期望每一次考试都是预先进行的，而是在他们的脑海中加入他们。

虽然你已经接受了你的问题的答案，但我想推荐几本尚未提及的书：

• 就我所知，这是唯一一本能够充分解决将现有代码转换为可测试代码的问题的书。作为更多的参考手册编写，它分为三个部分:工具和技术概述，遗留代码中常见路障的一系列专题指南，一组贯穿本书其余部分的特定的打破依赖技巧。
• 敏捷原则、模式和实践--RobertC.Martin-- java中的示例，在C#中有一个带有示例的后缀。两者都很容易适应C++。
• 清洁代码:敏捷软件工艺手册-RobertC.Martin-Martin将此描述为他的APPP书籍的前传，我同意。这本书证明了专业精神和自律，这是任何严肃的软件开发人员都必须具备的两个基本素质。

罗伯特(鲍勃叔叔)马丁的这两本书所涵盖的内容远远不止于单元测试，但它们让我们看到了单元测试对代码质量和效率有多大的益处。我发现自己经常提到这三本书。

在.NET中，我强烈推荐Roy的“单元测试艺术”，它非常全面，并且充满了好的建议。