单元测试不可测试那些类（无抽象、静态类、静态方法）

最新推荐文章于 2021-12-02 10:28:47 发布

???Sir

最新推荐文章于 2021-12-02 10:28:47 发布

阅读量708

点赞数 1

文章标签：测试 ui

原文链接：https://yq.aliyun.com/articles/350928

版权

实际上“单元测试不可测试那些类（无抽象、静态类、静态方法）”是个伪命题，因为事实是：无抽象、静态类、静态方法都是不可单元测试的。那么，如果我们要写出可测试的代码，又要用到这些静态类等，该怎么办，实际上我们需要两个步骤：

1：为它们写一个包装类，让这个包装类是抽象的（继承自接口，或者抽象类，或者方法本身是Virtual的）；

2：通知客户端程序员，使用包装类来代替原先的静态类来写业务逻辑；

实际上，微软也是这么干的，我在上一篇博文《单元测试WebForm的UI逻辑及文件上传》写到，最典型的不可测试类，那就是WebForm架构的网站中，对Response等的模拟。查看Response这个类：

namespace System.Web
{
    public sealed class HttpResponse
    {
        ...
    }
}

很明显，如果我们在某个WebForm的后台方法中，直接使用它的话：

protected void Page_Load(object sender, EvengArgs e)
{
  this.Response.Write("test u");
}

该后台代码逻辑就无法进行单元测试了，因为类似MOQ的框架所依赖的是代码本身具有可被重写行，如果某个类本身是静态的，就无法在运行时用模拟类替换掉实际类。

所以，写一个包装类吧，我们看到微软为Response写了一个包装类，为HttpResponseWrapper：

 
  View Code

光从代码本身的角度来说，可以说这个类什么事情也没做，但是它为我们提供了一个抽象体系（从抽象类HttpResponseBase继承），这样的话，我们的客户端代码就可以改写为：

protected HttpResponseBase _response;

protected void Page_Load(object sender, EvengArgs e)
{
  _response.Write("test u");
}

OK，可测试了，因为我们可以在某个地方注入依赖给_response了。

注意，包装类的撰写，还可以使用接口，或者干脆也仅仅只是一个类，只要让被包装的这个同名的方法是virtual的就可以了。

另外，不可测试的那些类，可能往往已经作为稳定版本提交给客户了，我们就不能修改源代码然后告诉客户说你替换下我们的DLL吧，所以，为了让客户端程序员找到我们的包装类，可以让包装类以及被包装的类使用同一个命名空间。

本文转自最课程陆敏技博客园博客，原文链接：http://www.cnblogs.com/luminji/archive/2012/12/31/2840455.html，如需转载请自行联系原作者

关注