1

我有一个方法CreateTask(UserId)。

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

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

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

4

2 回答 2

1

我认为这里没有足够的信息来回答这个问题。但是我解决了你的一些观点：

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

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

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

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

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

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

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

例如，假设您有MethodA()没有被任何测试使用的。没有测试直接调用它，因为它只是一个实现细节，测试不需要知道它。（在这种情况下，将方法设为私有或以其他方式从外部调用代码中隐藏可能是有意义的。）这给您留下了两个选择：

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

如果您的测试盲目地测试每个方法，而不管业务逻辑的大局如何，您将永远无法确定系统何时不需要某些东西。弃用不再需要的代码是保持简单且可维护的代码库的重要部分。

于 2013-10-22T09:58:06.317 回答
0

1) 保持你的方法简短和简单，这样单元测试就会很容易（顺便说一句。TDD鼓励好的设计的原因之一）

2）检查所有边界条件（无效输入，琐碎输入等）（顺便说一句。使TDD容易的方法之一）

3）检查所有可能的场景以实现高覆盖率（所有可能的执行流程通过您的方法以最简单的输入来实现这一点）（顺便说一句。TDD工作的原因之一）

4）用真实数据检查几个（可能是一个）典型场景，这些场景展示了该方法的典型用法

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

于 2013-10-22T09:52:59.890 回答