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

从单元测试和依赖注入的角度来看，当涉及到辅助方法时，通常采用的规范是什么？依赖注入和单元测试 - 静态辅助方法或私有实例方法

这里是我的例子情况：

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？

来源

2017-02-09 legen---wait for it---dary

这真的取决于你的YouLikeThemThisWay(string path)方法。我的规则使用静态方法或如下：

它是否需要一个非原始的依赖？如果是这样，请勿使用静态。
它会影响应用程序的状态吗？如果是这样，请勿使用静态。
它是否扩展了您无权访问的类或类型的功能（IE BCL类或primative）？如果这样使用静态扩展！
它是否会影响单元测试 - 如果我不能嘲笑例程，那么它会更难吗？如果不是，那就把它变成静态的！
它会被多个类型或类使用吗？如果这样，它使它成为静态更好的候选者！
例程是否执行某种IO，如调用数据库或文件系统？如果是这样，我不会让它变成静态的。

基本上，小型助手功能，很容易测试，不影响状态或通常可以静态。如果涉及到状态，则例程需要通常注入的依赖项，或者例程正在进行IO或IPC调用，然后不要使其静态。

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

重复使用也是静态的一个重要因素。如果该例程只能在一个类中使用，则静态化可能毫无意义。我的大多数静态方法都存在于随处可以轻松访问的辅助类中。

编辑：请注意，我通常需要大多数或所有这五个规则来支持静态，以便我甚至可以考虑做出静态的东西。

来源

2017-02-09 14:59:30 Carson

我不认为我完全得到第2点。该方法基本上不会调用任何外部资源。它只是在提供的输入上工作。 –

首先我想把它放在'context'中，问题是我真的需要嘲笑它还是只是叫它（即把它从'context'中取出，因此我的问题是'static'或'private'） –

点＃2意味着你正在考虑使静态的方法影响应用程序的全局状态，IE是否会改变某处不能'撤消'的地方，因此你不能连续多次执行该函数相同的结果。静态函数应该总是[幂等]（https://en.wikipedia.org/wiki/Idempotence） – Carson

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

回答

相关问题