我将如何进行单元测试？

Question

我需要开发一个相当简单的算法，但我对如何最好地为其编写测试感到有点困惑。

一般描述：用户需要能够删除计划。计划有与之关联的任务，这些任务也需要删除（只要它们尚未完成）。

伪代码作为算法的行为方式：

   PlanController.DeletePlan(plan)
     =>
     PlanDbRepository.DeletePlan()
      ForEach Task t in plan.Tasks
          If t.Status = Status.Open Then
            TaskDbRepository.DeleteTask(t)
          End If
      End ForEach

现在据我了解，单元测试不应该接触数据库或通常需要访问任何外部系统，所以我猜我这里有两个选择：

1) 模拟存储库调用，并检查它们是否作为断言被调用了适当的次数

2) 为两个存储库类创建存根，手动设置其删除标志，然后验证是否有适当的对象已被标记为删除。

在这两种方法中，最大的问题是：我在这里到底要测试什么？此类测试会给我带来什么额外价值？

对此的任何见解都将受到高度赞赏。尽管我们有 RhinoMocks 可供使用，但从技术上讲，这与任何特定的单元测试框架无关。但我更喜欢一个一般性的解释，这样我就可以正确地理解这一点。

Answer 1

您应该模拟存储库，然后在包含开放任务和封闭任务的单元测试中构建一个虚拟计划。然后调用传递此计划的实际方法，并最后验证是否使用正确的参数调用了 DeleteTask 方法（仅状态 = Open 的任务）。这样您就可以确保您的方法仅删除与该计划关联的未完成任务。另外，不要忘记（可能在单独的单元测试中）通过断言已在您传递的对象上调用 DeletePlan 方法来验证计划本身是否已被删除。

Answer 2

为了补充达林的答案，我想告诉您您实际正在测试的内容。其中有一些业务逻辑，例如状态检查。

这个单元测试现在看起来可能有点愚蠢，但是未来对代码和模型的更改又如何呢？为了确保这个看似简单的功能始终保持工作状态，此测试是必要的。

Answer 3

正如您所指出的，您正在测试算法中的逻辑是否按预期运行。你的方法是正确的，但考虑一下未来 - 几个月后，这个算法可能需要改变，不同的开发人员将其砍掉并重做，遗漏了一个关键的逻辑。您的单元测试现在将失败，并且开发人员将收到关于他们的错误的警报。单元测试在开始时很有用，在接下来的几周/几个月/几年里也很有用。

如果您想添加更多，请考虑如何处理失败。让您的数据库模拟在删除命令上抛出异常，测试您的算法是否正确处理此问题。

Answer 4

测试提供的额外价值是检查您的代码是否执行正确的操作（在这种情况下，删除计划，删除与计划关联的任何打开的任务并保留与计划关联的所有已关闭的任务）。

假设您已经对 Repository 类进行了测试（即，当调用它们时，它们会执行正确的操作），那么您需要做的就是检查是否适当地调用了删除方法。

您可以编写的一些测试是：
删除空计划是否只调用DeletePlan？
删除包含两个开放任务的计划是否会为这两个任务调用 DeleteTask ？
删除包含两个已关闭任务的计划是否根本不会调用 DeleteTask ？
删除包含一个打开的任务和一个关闭的任务的计划是否会在正确的任务上调用一次 DeleteTask ？

编辑：我会使用达林的答案作为解决问题的方法。

Answer 5

有趣的是，我发现单元测试有助于将注意力集中在规范上。
为此，让我问这个问题...

如果我有一个包含 3 个任务的计划：

Plan1 {
 Task1: completed
 Task2: todo
 Task3: todo
}

并且我对它们调用删除，那么该计划会发生什么？

Plan1 : ?
Task1: not deleted
Task2: deleted
Task3: deleted

plan1 是否被删除，任务 1 被孤立？或者是否以其他方式标记为已删除？

这是我在单元测试中看到的值的很大一部分（尽管它只是 4 个值中的 1 个：
1) 规格
2）反馈
3）回归
4）粒度

至于如何测试，我根本不建议使用mock。我会考虑两部分方法
第一个看起来像

public void DeletePlan(Plan p)
{ 
  var objectsToDelete = GetDeletedPlanObjects(p);
  DeleteObjects(objectsToDelete);
} 

我不会测试这个方法。
我将测试 GetDeletedPlanObjects 方法，该方法无论如何都不会接触数据库，并且允许您发送类似上述情况的场景......然后我将使用 www.approvaltests.com 进行断言，但这是另一个故事：- ）

快乐测试，
卢埃林

Answer 6

我不会为此编写单元测试，因为对我来说这不是测试行为而是测试实现。如果在某些时候您希望不删除任务而是将它们设置为“禁用”或“忽略”状态，那么您的单元测试将会失败。如果您以这种方式测试所有控制器，您的单元测试将非常脆弱，并且需要经常更改。

如果您想测试业务逻辑并将删除的实现细节留给类本身，请将业务逻辑重构为“TaskRemovalStrategy”。

Answer 7

在我看来，您可以围绕抽象的 PlanRepository 编写单元测试，相同的测试对于测试数据库中的数据完整性也应该很有用。

例如，您可以编写一个测试 -

void DeletePlanTest()
{
    PlanRepository repo = new PlanDbRepository("connection string");
    repo.CreateNewPlan(); // create plan and populate with tasks
    AssertIsTrue(repo.Plan.OpenTasks.Count == 2); // check tasks are in open state
    repo.DeletePlan();
    AssertIsTrue(repo.Plan.OpenTasks.Count == 0);
}

即使您的存储库删除了计划并且您的数据库通过级联删除触发器删除了相关任务，该测试也将起作用。

此类测试的价值在于，无论测试是针对 PlanDbRepository 还是针对 MockRepository 运行，它仍然会检查行为是否正确。因此，当您更改任何存储库代码甚至数据库架构时，您可以运行测试来检查是否没有损坏。

您可以创建此类测试，涵盖存储库的所有可能行为，然后使用它们来确保您的任何更改都不会破坏实现。

您还可以使用具体的存储库实例参数化此测试，并重用它们来测试存储库的任何未来实现。