如何做单元测试

Question

我有一个方法CreateTask(UserId)。

对于这种方法，是否足以检查UserId对null或空和无效值？

或者我应该检查是否为特定的UserId创建了Task？

还应该检查创建的任务数量及其日期和时间吗？

Answer 1

我不认为这里有足够的信息来回答这个问题。但ti地址的一些要点：

对于这种方法，是否足以检查UserId null或空和无效的ID？

该方法本身可以在内部做到这一点，但这不是测试的一部分。这只是在运行时进行一些错误检查的方法。这通常被称为“防御性编程”。

或者我应该检查是否为指定的UserId创建了Task。

这就是阴天。这就是你想要退一步看看更大的图景的地方。确保你没有将你的单元测试与你的实现逻辑紧密结合。测试应该验证业务逻辑，不知道实现。

这是极有可能“创建任务”不是业务逻辑，而只是一个实现细节。你应该测试的是当执行步骤A时，观察结果B.系统如何产生结果B基本上是测试内容，但不是直接或明确的。

像这样保持高级单元测试的一个重要原因是因为如果实现细节发生变化，那么您不需要用它们来更改测试。这大大降低了这些测试的价值，因为它不仅增加了更多的工作，而且还消除了测试作为这些更改的验证点，因为测试本身也更改。测试应该相当简单和静态，作为一组用于验证代码的规则。如果测试很复杂并且经常发生变化，那么他们将失去验证代码所需的信任程度。

您不必测试每种方法。您应该测试系统执行的每个可观察的业务操作。执行这些操作的方法因此得到测试。那些不执行这些操作的方法，首先是否需要这些操作是有问题的。代码覆盖工具非常适合于确定这一点。

例如，假设您有MethodA()哪个未被任何测试使用。没有测试直接调用它，因为它只是一个实现细节，测试不需要知道它。 （在这种情况下，它甚至可能是有意义的方法是私有的或从外部调用代码掩盖一些其他的方式）。这让你有两种选择：

1. 测试是不完整的，因为需要MethodA()通过未经测试的业务流程。为该业务流程添加测试。
2. 测试完成，并且MethodA()实际上不是系统所需要的。去掉它。

如果您的测试盲目地测试每种方法，而不考虑业务逻辑的全貌，那么您永远无法确定何时系统不需要某些东西。弃用不再需要的代码是保持简单且可维护的代码库的一个重要组成部分。

Answer 2

1）保持你的方法简短，所以单元测试将是容易（顺便说一句，的原因之一TDD鼓励良好的设计）

2）检查所有的边界条件（输入无效的，琐碎的输入等）

3）检查所有可能的方案，以实现高覆盖率（的方式，使TDD容易BTW。一个）（所有可能的执行流过你的方法用简单的输入来实现这一点）（顺便说一句，原因之一是TDD作品）

4）检查几个（也许一个）真实数据典型场景，演示方法

正如你可能已经注意到的典型用法 - 考虑使用TDD这样你就不必担心“测试现有的方法”的问题:)