很简单，我想知道的是，有没有办法对这段代码进行干净的单元测试？我可以实例化它并运行一些断言，但我的意思是实际的单元测试，我将在其中模拟服务对象以删除被测类的任何依赖关系，并实际上让它只测试这个类而不是它的依赖服务（在本例中为 ConcreteService）。
public class Foo{
public SomeResult DoSomething(){
var service = new ConcreteService();
var foo = service.Execute();
return foo;
}
}
我的正常方法是在我的代码主体中不创建这种类型的对象，但是在无法更改的情况下，我有哪些单元测试选项？
【问题讨论】：
标签： c# .net unit-testing dependency-injection
鉴于限制（您不能修改/重新编译该代码），恐怕除了“集成测试”之外您无能为力 - 真正的依赖关系，缓慢的测试.
在方法中实例化一个依赖，而不是接受它作为一个 ctor 或方法参数会使事情变得困难。
正如 Ethan 所说，有痣（但对我个人而言，它似乎并不正确）。我更喜欢设计更改，而不是帮助我掩盖设计问题的框架。
【讨论】：
如果 service.Execute() 是虚拟的，那么大多数模拟框架都支持这一点。我个人使用Rhino.Mocks。
请参阅this question，其中详细介绍了在非接口上使用 Mocking 框架的功能，并讨论了 Mocking 框架拦截虚拟调用的功能。
如果它不是虚拟的，并且您无法更改它，那么您可以使用Moles。上面提到的帖子还提到了使用TypeMock的能力，我个人没有用过。
微软研究网站上对 Moles 的描述：
Moles 是一个轻量级的框架，用于 .NET 中基于委托的测试存根和迂回。 Moles 可用于绕过任何 .NET 方法，包括密封类型中的非虚拟/静态方法。
【讨论】：
ConcreteService，但对Execute 的调用被拦截。
我知道您提到这将是您无法更改的情况的一个示例，但我会努力重构该类，以便可以将 ConcreteService 作为依赖项注入。重构是尝试解决糟糕设计的一种更简单的方法。从您发布的内容来看，我认为您没有理由不能这样做。
编辑： FWIW，我同意@Gishu。如果你绝对不能修改类，例如你不拥有它并且你没有能力修改它，那么集成测试是最好的方法。然而，如果你能看到代码和它在做什么，我支持我之前所说的，你真的没有理由不重构。
【讨论】：