单元测试类的最佳实践，主要负责调用依赖项的方法，但也包含逻辑

Question

bounty到期在7天内。这个问题的答案有资格获得+ 200声望赏金。Ezio Auditore da Firenze想要引起更多关注来回答这个问题。

假设我有StartCommandHandler，它负责使用所需文件创建一些文件。但是为此，我必须给他设置一些子职责，例如：

• 检查FTP中是否存在文件
• 如果不是，则将文件从多个来源下载到临时文件夹中
• 然后在文件夹中执行一些脚本
• 然后在脚本执行后读取生成的文件
• 然后从该文件夹创建zip
• 然后删除该文件夹
• 然后更新数据库

作为该命令处理程序的结果，我们正在创建包含所有必需文件的文件夹。现在，该文件夹已准备好进行其他操作。

我刚刚读了"Art of the Unit testing"。并开始添加单元测试。我也遵循SOLID原则。特别是SRP和DIP，我认为它们是单元测试的先决条件。因此，我上面所说的大多数事情都是通过特定的接口完成的。因此，该命令处理程序的90％的工作是调用依赖项的方法。 10％是这样的逻辑：

if(!_dependency1.IsAnySomething())
{
     _dependency2.Download();

      var isScriptNeeded = _dependency2.IsScriptNeeded();

      if(isScriptNeeded)
      {
          var res = _dependency3.ExecuteScript();
         _dependency4.SetScriptResult(res.Info, res.Date, res.State);
      }

     _dependency3.Archive();

     _dependency5.DeleteTemp();
}

我已经测试了该命令处理程序的所有依赖关系。但是，帽子命令处理程序还包括一些小的逻辑，例如，是否需要下载文件，或是否删除了临时文件，等等...

我在脑海中有很多问题，例如：

1. 也许单元测试对这样的单元没有意义吗？集成测试可以营救吗？因为，测试是否检查所有调用似乎是错误的，例如在下载后是否调用了DeleteTemp或是否执行了脚本，或者[脚本结果以正确的方式传递到[C0 ] 方法。是好的单元测试吗？
2. 是否有任何方法可以重构该类以使其可测试？

Answer 1

您也可以对此方法使用单元测试。这可以通过模拟依赖关系来完成。原理如下：

您创建具有预定义结果的依赖项模拟（通常通过实现依赖项的接口）。例如，您为SetScriptResult提供了一个实现，该实现始终为dependency2返回true。

然后监视IsScriptNeeded()并检查它是否被调用（应该是！），以及dependency3的参数是否与结果匹配。

对于C＃，有FakeItEasy和Moq之类的库，使模拟变得轻而易举。使用xUnit和FakeItEasy的示例代码片段：

dependency4.SetScriptResult(...)