测试静态方法与测试任何其他方法没有什么不同。将静态方法作为 依赖关系 在另一个经过测试的模块中会引发问题（如前所述-
您无法使用免费工具对其进行模拟/存根）。但是，如果静态方法本身已经过单元测试，则可以简单地将其视为有效的可靠组件。
总体而言，在以下情况下，使用静态方法没有任何问题（例如，不会破坏单元测试/ TDD）：
- 这是简单的输入输出方法（各种 “给定的计算” ）
- 它是 可靠的 ，也就是说我们已经对它进行了测试，或者来自您认为可靠的第三方来源（例如，
Math.Floor
可能被认为是可靠的-使用它不应发出 “ 注意 ，这是静态的！” 警告；您可能会假设微软做到了）
静态方法何时会引起问题，应避免使用？基本上，只有当他们与 您 互动或 做一些您无法控制 （或模拟）的 事情时 ：
- 各种文件系统，数据库，网络依赖项
- 从内部调用的其他（可能是更复杂的）静态方法
- 您的模拟框架无法正常处理的几乎所有内容
编辑： 就当静态方法两个例子 将 使得单元测试硬盘
1个
public int ExtractSumFromReport(string reportPath){ var reportFile = File.ReadAllText(reportPath); // ...}你如何处理
File.ReadAllText？很显然，这将进入文件系统以检索文件内容，这在单元测试时是主要的禁止。这是具有外部依赖关系的静态方法的示例。为了避免这种情况，通常可以围绕文件系统api创建包装器，或者只是将其作为依赖项/委托注入。
2
public void SaveUser(User user){ var session = SessionFactory.CreateSession(); // ...}那这个呢？会话 是非平凡的
依赖关系。当然，它可能是
ISession，但是如何强制
SessionFactory返回模拟？我们不能。而且我们也无法创建 易于确定的 会话对象。
在上述情况下，最好完全避免使用静态方法。
