单元测试的新手，如何编写出色的测试？[关闭]

我对单元测试世界还很陌生，所以我决定在本周为现有应用程序增加测试范围。

这是一项艰巨的任务，主要是因为要测试的类数量众多，而且因为编写测试对我而言是全新的。

我已经为很多类编写了测试，但是现在我想知道自己是否做对了。

当我为某个方法编写测试时，我有第二次重写已经在该方法本身中编写的内容的感觉。
我的测试似乎与方法紧密绑定（测试所有代码路径，期望某些内部方法被调用多次，并带有某些参数），以至于即使我重构了该方法，即使该方法的最终行为没有改变。

这只是一种感觉，正如前面所说，我没有测试经验。如果那里有一些经验更丰富的测试人员可以给我一些有关如何为现有应用编写出色测试的建议，将不胜感激。

编辑：非常感谢Stack Overflow，我在不到15分钟的时间内就得到了很多建议，回答了我刚才所做的更多在线阅读时间。

我的测试似乎与方法紧密绑定（测试所有代码路径，期望某些内部方法被调用多次，并带有某些参数），以至于即使我重构了该方法，即使该方法的最终行为没有改变。

我认为您做错了。

单元测试应：

• 测试一种方法
• 提供该方法的一些特定参数
• 测试结果是否符合预期

它不应查看方法内部以查看其作用，因此更改内部结构不应导致测试失败。您不应该直接测试正在调用私有方法。如果您有兴趣了解是否正在测试您的私人代码，请使用代码覆盖率工具。但是不要被这个困扰：100％的覆盖率不是必需的。

如果您的方法在其他类中调用了公共方法，并且您的接口保证了这些调用，那么您可以使用模拟框架测试是否正在进行这些调用。

您不应使用方法本身（或方法使用的任何内部代码）来动态生成预期结果。预期结果应硬编码到您的测试用例中，以便在实现发生更改时也不会更改。这是单元测试应做的简化示例：

testAdd()
{
    int x = 5;
    int y = -2;
    int expectedResult = 3;
    Calculator calculator = new Calculator();
    int actualResult = calculator.Add(x, y);
    Assert.AreEqual(expectedResult, actualResult);
}

请注意，未检查结果的计算方式-仅检查结果是否正确。像上面那样继续添加越来越多的简单测试用例，直到您涵盖了尽可能多的场景为止。使用代码覆盖率工具来查看是否错过了任何有趣的路径。

对于单元测试，我发现“测试驱动”（首先测试，然后是代码）和“代码首先是测试”都非常有用。

而不是编写代码，而是编写测试。编写代码，然后查看您认为代码应该做什么。考虑一下它的所有预期用途，然后为每个用途编写一个测试。我发现编写测试比编写代码要快，但要涉及的更多。测试应该测试意图。还考虑一下在编写测试阶段最终找到极端案例的意图。当然，在编写测试时，您可能会发现导致错误的几种用法之一（我经常发现的东西，我很高兴这个错误没有破坏数据并且不受检查）。

但是测试几乎就像两次编码一样。实际上，我的应用程序中测试代码（数量）比应用程序代码多。一个例子是非常复杂的状态机。我必须确保在向其中添加更多逻辑之后，整个过程始终适用于所有以前的用例。而且由于很难通过查看代码来跟踪这些情况，因此我为该机器准备了一个很好的测试套件，以至于我坚信即使进行更改，它也不会损坏，并且测试节省了我的几次钱。当用户或测试人员发现错误或无法解决的错误时，请猜测是什么，将其添加到测试中，再也不会发生。除了使整个过程超级稳定之外，这确实使用户对我的工作充满信心。当出于性能原因而不得不对其进行重写时，请猜测是什么，

所有这些简单的例子function square(number)都是很棒的，并且可能是花费大量时间测试的不佳之选。那些执行重要业务逻辑的人，那就是测试很重要的地方。测试需求。不要只是测试管道。如果需求发生变化，则猜测是什么，测试也必须如此。

测试不应从字面上测试该函数foo调用功能栏3次。那是错的。检查结果和副作用是否正确，而不是内部机制。

值得注意的是，将单元测试改编为现有代码是 远远比驾驶代码的创建与第一名的测试更加困难。那是处理遗留应用程序时的主要问题之一……如何进行单元测试？之前已经问过很多次了（所以您可能会被问到一个重复的问题），人们通常会在这里结束：

将现有代码移至测试驱动开发

我将接受答案的书建议列为第二，但除此之外，答案中还有更多信息链接。

不要编写测试来完全覆盖您的代码。编写满足您要求的测试。您可能会发现不必要的代码路径。相反，如果有必要，它们可以满足某种要求。找到它并测试需求（而不是路径）。

保持较小的测试：每个要求进行一次测试。

以后，当您需要进行更改（或编写新代码）时，请尝试首先编写一个测试。只有一个。然后，您将迈出测试驱动开发的第一步。

单元测试是关于您从功能/方法/应用程序获得的输出的。结果的产生方式根本不重要，正确的意义也很重要。因此，您计算内部方法调用等的方法是错误的。我倾向于做的是坐下来，写下给定某些输入值或特定环境的方法应返回的内容，然后编写一个测试，将返回的实际值与我想出的结果进行比较。

在编写要测试的方法之前，请尝试编写单元测试。

这肯定会迫使您对事情的完成方式有所不同。您将不知道该方法将如何工作，只知道它应该做什么。

您应该始终在测试方法的结果，而不是方法如何获得这些结果。

测试应该改善可维护性。如果您改变方法并且测试中断可能是一件好事。另一方面，如果您将方法视为黑匣子，则方法内部的内容无关紧要。事实是您需要对某些测试进行模拟，在这些情况下，您实际上无法将方法视为黑盒。您唯一可以做的就是编写一个集成测试-您加载被测试服务的完全实例化的实例，并使其像在应用程序中运行一样进行。然后，您可以将其视为黑匣子。

When I'm writing tests for a method, I have the feeling of rewriting a second time what I          
already wrote in the method itself.
My tests just seems so tightly bound to the method (testing all codepath, expecting some    
inner methods to be called a number of times, with certain arguments), that it seems that
if I ever refactor the method, the tests will fail even if the final behavior of the   
method did not change.

这是因为您是在编写代码后编写测试的。如果您反过来做（首先编写测试），则不会有这种感觉。