依赖注入和单元测试——静态辅助方法或私有实例方法

Question

从单元测试和依赖注入的角度来看，辅助方法通常采用的规范是什么？

这是我的示例情况：

public class GoodiesController : Controller
{
   private IMyContext _context;

   public GoodiesController(IMyContext context)
   {
      _context = context
   }

   public async Task<IAction> GetThoseGoodies()
   { 
       if(YouLikeThemThisWay(Request.Path))
        {
           var result = await _context.GoGetThemThisWay()
        } else { }
    }

我的问题是我最好将YouLikeThemThisWay(string path) 作为某个类中的静态助手还是作为私有实例方法？假设我可能有几个 YouLikeThemThisWay 之类的？

Answer 1

这实际上取决于您的 YouLikeThemThisWay(string path) 方法的作用。我使用静态方法的规则或如下：

1. 它是否需要非原始依赖？如果是这样，请不要使用静态。
2. 它会影响应用程序的状态吗？如果是这样，请不要使用静态。
3. 它是否扩展了您在内部无法访问的类或类型（IE BCL 类或原语）的功能？如果是这样，请使用静态扩展！
4. 如果我不能模拟例程，它会影响单元测试吗？如果不是，则将其设为静态！
5. 会被多个类型或类使用吗？如果是这样，它会成为更好的静态候选者！
6. 例程是否执行某种 IO，例如调用数据库或文件系统？如果是这样，我不会让它成为静态的。

基本上，易于测试且不会影响状态或通常可以制作静态的小型辅助函数。如果涉及到状态，则例程需要一个您通常会注入的依赖项，或者例程正在进行 IO 或 IPC 调用，则不要将其设为静态。

对依赖问题的一个警告是，从技术上讲，您可以使用方法注入来处理依赖关系，但我喜欢保持简单。您的方法可能是静态的。

重用也是静态的一个重要因素。如果例程只在一个类中使用，则将其设为静态可能毫无意义。我的大多数静态方法都存在于可以在任何地方轻松访问的辅助类中。

编辑：请注意，我通常需要这五个规则中的大部分或全部来支持静态，以便我什至考虑制作静态的东西。