好的，我知道单元测试是什么，但是我在一些项目中使用它而不是其他项目......一些客户不知道它是如何完成的并遵循一个约定......等等等等。
所以我在这里问，单元测试过程是如何创建的？ 我听到并读到，您先编写测试然后编写功能并编写该功能的测试，并使用代码覆盖率来识别没有测试该代码的任何“滑动”，这些测试尚未涵盖。
所以，让我们使用一个简单的例子：
要求：“申请必须返回2个数字的结果。”
你和我知道我们会有一个类，比如“Addition”和一个方法“Add”，它返回一个如下的整数：
public class Addition
{
public int Add(int num1, int num2)
{
return num1 + num2;
}
}
但即使在写这门课之前，你又如何编写测试？你的过程是什么？你是做什么？当你拥有那个规范文档并进入开发阶段时，这个过程会是什么？
非常感谢，
答案 0 :(得分：5)
您所指的流程称为Test-Driven Development。想法很简单，接近你所描述的;给定功能，您可以通过编写此功能的测试来开始编写代码。在您的添加示例中，之前编写任何正在运行的代码，您应该进行简单的测试 - 测试失败。
[Test]
public void TestAdd()
{
var testedClass = new Addition();
var result = testedClass.Add(1, 2);
Assert.AreEqual(result, 3);
}
这是对.Add方法的简单测试，说明您对即将运行的代码的期望。由于你还没有任何代码，这个测试自然会失败（因为它应该 - 这很好）。
下一步是编写最基本的代码，使测试通过（自然，最基本的代码是return 3;但是对于这个简单的例子，这个级别的细节是没必要）：
public int Add(int num1, int num2)
{
return num1 + num2;
}
这是工作和测试通过。你在这一点上所拥有的，基本证明你的方法在你的假设/期望（测试）中以你所说的方式工作。
但是，你可能会注意到这个测试不是很好;它只测试一个简单的输入数据。更不用说，在某些情况下，一个测试可能还不够，即使你有初始要求，测试可能会发现需要更多（例如参数验证或记录）。当你回到审查你的要求和编写测试时，这就是这个部分，这导致我们......
此时你应该编写refactor代码。我正在谈论两个单元测试方法代码和测试实现。由于Add方法相当简单，并且在添加两个数字方面没有太多改进，因此您可以专注于更好地进行测试。例如：
像这样：
[TestCase(0, 0, 0)]
[TestCase(1, 2, 3)]
[TestCase(1, 99, 100)]
public void Add_ReturnsSumOfTwoNumbers(int first, int second, int expectedSum)
{
var testedClass = new Addition();
var actualSum = testedClass.Add(first, second);
Assert.That(actualSum, Is.EqualTo(expectedSum));
}
重构是值得拥有的主题（也有很多），所以我不会详细介绍。我们刚刚经历的过程通常被称为 Red-Green-Refactor （红色表示测试失败，绿色表示通过），它是TDD的一部分。请记住再次重新运行测试，以确保重构不会意外破坏任何内容。
这是基本周期的方式。您从需求开始，为其编写失败测试，编写代码以使测试通过，重构代码和测试，审查要求，继续执行下一个任务。
一旦你了解了TDD背后的想法（即使从这篇文章中提供的简短解释），很少有有用的资源是良好的自然跟进：