TDD学习笔记【五】一隔绝相依性的方式与特性

前端之家收集整理的这篇文章主要介绍了TDD学习笔记【五】一隔绝相依性的方式与特性前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

前言

上一篇文章中,提到了如何通过 IoC 的设计,以及 Stub Object 的方式,来独立测试目标对象。

这一篇文章,则要说明有哪些设计对象的方式,可以让测试或需求变更时,更容易转换。

并说明这些方式有哪些特性,供读者朋友们在设计时,可以选择适合自己情境的方式来使用。

需求说明

调用目标对象的方法时,期望目标对象的内容可以不必关注相依于哪些实体对象,而只需要依赖于某个接口,通过这样的方式来达到设计的弹性与可独立测试性。

那么,有哪一些方式可以达到这样的目的呢?

构造函数(constructor)

描述:

上一篇文章范例所使用的方式,将对象的相依接口,拉到公开的构造函数,供外部对象使用时,可自行组合目标对象的依赖对象实体。

public class Validation
{
    private IAccountDao _accountDao;
    private IHash _hash;

    public Validation(IAccountDao dao,IHash hash)
    {
        this._accountDao = dao;
        this._hash = hash;
    }

    bool CheckAuthentication(string id,string password)
    {
        var passwordByDao = this._accountDao.GetPassword(id);
        var hashResult = this._hash.GetHashResult(password);

        return passwordByDao == hashResult;
    }
}

好处:

有许多 DI framework 支持 Autowiring。

Autowiring is an automatic detection of dependency injection points.

这里的 dependency injection points 在这例子,指的就是构造函数以 Unity 为例,在 UnityContainer 取得目标对象时,会自动寻找目标对象参数最多的构造函数并针对每一个参数的类型,继续在 UnityContainer 中寻找对应的实体对象,直到目标对象组合完毕,回传一个完整的目标对象。

由构造函数传入依赖接口的实体对象,是一个很通用的方式。因此在结合许多常见的 DI framework,不需要再额外处理。

顾虑点:

当对象越来越复杂时,构造函数也会趋于复杂。倘若没有 DI framework 的辅助,则使用对象上,面对许多 overload 的构造函数,或是一个构造函数的参数有好几个,会造成使用目标对象上的困难与疑惑。若没有好好进行 refactoring,也可能因此而埋藏许多 bad smell。

另外,倘若是许多构造函数,也可能造成要调用 A 方法时,应选用 A 对应的构造函数,但在使用对象上,可能会用错构造函数而不自知,若方法中没有正确的防呆,则可能出现错误(请搭配单元测试的测试案例来辅助)

最后,与原本直接依赖的程序代码相比较,目标对象的相依对象因此暴露出来,交由外部决定,而丧失了一点封装的意味。而使用端也不一定知道,要取用此对象时,应该要注入哪些相依对象。(请使用 Repository Pattern 或 DI framework 来辅助)

公开属性(public setter property)

其实公开属性与公开构造函数非常类似,通过 public 的 property(property类型仍为 interface),让外部在使用目标对象时,可先 setting 目标对象的相依对象,接着才调用方法

而公开属性通常只会将 setter 公开给外部设定,getter 则设定为 private。原因很简单,外部只需设定,而不需取用。就像公开构造函数,在使用对象之前先传入初始化对象必备的信息,但目标对象可能将这些信息,存放在 private 的 filed 或 property 中,而不需再提供给外部使用。

程序代码如下:

bool CheckAuthentication(IAccountDao accountDao,IHash hash,255); line-height:1.5!important">string password)
{
    var passwordByDao = accountDao.GetPassword(id);
    var hashResult = hash.GetHashResult(password);

    return passwordByDao == hashResult;
}

好处:

不必再担心要先初始化哪些 property,或调用哪一个构造函数当要调用某一个方法,其相依的对象,就是得通过参数来给定。基本上也不太需要担心使用上造成困扰或迷惑。

顾虑点:

最大的问题,在于方法签名上的不稳定性。当需求异动,该方法需要额外相依于其他对象时,方法签名可能会被迫改变。方法签章是面向对象设计上,最需要稳定的条件之一。以面向对象、接口导向设计来说,当多态对象方法签名不一致时,向来是个大问题。

另外,方法的参数过多,在使用上也会造成困扰。而且会影响到 legacy code 的调用端,需要全面跟着异动,才能编译成功。

而且通过参数的方式,DI framework 支持度较低。

但这不代表,就不能在方法参数中,传入相依对象。在 .net framework 还是有许多这样的设计,例如:List<T>.Sort 方法 (IComparer<T>)这样的设计方式,通常要确保该方法相依相当明确、稳固,避免上述问题。

by the way,这个方式是可以与其他方式共存的,所以在设计对象时,可衡量搭配使用。

可覆写的保护方法(protected virtual function)

描述:

前面的三种方式,基本上都对外暴露了原本可能不需要对外暴露的细节。倘若,现在的需求是眼前的程序要进行测试,但又不希望影响或修改使用端的程序,那么该怎么作呢?除了可以透过公开属性设定,当为空时给予默认值的方式,来维持原本对象的内部程序逻辑以外,还有一个相当简单的方式,甚至有些情况不需要透过接口设计,就可以进行测试。先来看看原本直接依赖对象,无法测试的程序,程序代码如下:

var accountDao = new AccountDao();
        var passwordByDao = accountDao.GetPassword(id);

        var hash = new Hash();
        var hashResult = hash.GetHashResult(password);

        return passwordByDao == hashResult;
    }
}

接下来,我们只用简单的面向对象概念:继承、重写,就可以对 Validation 对象的 CheckAuthentication 方法进行测试。不相信吗?继续往下看下去。

首先,一定要记得,把 new 对象的动作抽离高层抽象的 context(可以透过 extract method 的方式抽离)程序代码如下

var accountDao = GetAccountDao(); var hash = GetHash(); return passwordByDao == hashResult; } private Hash GetHash() { return hash; } private AccountDao GetAccountDao() { return accountDao; } }

没什么改变,对吧?

接下来,将两个 new 对象的方法,声明为protected virtual,代表子类别可以继承与重写该方法程序代码如下:

protected virtual Hash GetHash() { new Hash(); return hash; } virtual AccountDao GetAccountDao() { new AccountDao(); return accountDao; }

另外,将要使用到 Hash 与 AccountDao 的方法,也要声明为virtual程序代码如下:

class AccountDao { virtual string GetPassword(string id) { throw new NotImplementedException(); } } class Hash { string GetHashResult(new NotImplementedException(); } }

到这里,都不影响外部使用目标对象的行为,我们只是在重构对象的内部方法罢了。事实上,我们可测试性的动作也准备完毕了。(当然,建议还是要依赖于接口,实现接口要顾虑的点,比继承类要轻松的多)

接下来把目光切到测试程序,该如何对 CheckAuthentication 方法进行测试。

首先,将上一篇文章的 StubHash 改为继承自 Hash,StubAccountDao 改为继承自 AccountDao,并将原本 public 的方法加上override关键词,重写其父类方法内容程序代码如下:

class StubAccountDao : AccountDao { override return "Hello World"; } } class StubHash : Hash { "; } }

不难,对吧。接下来,建立一个 MyValidation 的 class,继承自 Validation。并重写 GetAccountDao() 与 GetHash(),使其回传 Stub Object。程序代码如下:

class MyValidation : Validation { override AccountDao GetAccountDao() { return new StubAccountDao(); } override Hash GetHash() { new StubHash(); } }

也不难,对吧。接下来,来设计单元测试,程序代码如下:

[TestMethod()]
void CheckAuthenticationTest()
{
    Validation target = new MyValidation();

    string id = "id随便";
    string password = "密码也随便";

    bool expected = true;

    bool actual;
    actual = target.CheckAuthentication(id,password);

    Assert.AreEqual(expected,actual);
}

原本初始化的测试目标为 Validation 对象,现在则为 MyValidation 对象。里面唯一不同的部分,只有重写的方法内容,其余 MyValidation 就等同于 Validation。Is-A的关系)调试测试一下,就可以确认,程序代码就跟之前使用 IoC 的方式执行没有太大的差异。

好处:

这个方式最大的好处,是完全不影响外部使用对象的方式。仅透过 protected 与 virtual 来对继承链开放扩充的功能,并且透过这样的方式,就使得原本直接相依而导致无法测试的问题,获得解套。

顾虑点:

这是为了测试,且面对 legacy code 所使用的方式,而不是良好的面向对象设计的方式。IoC 的用意在于面向借口与扩充点的弹性,所以当可测试之后,倘若重构影响范围不大,建议读者朋友还是要将对象改依赖于接口,通过IoC 的方式来设计对象。

by the way,同样为了解决直接相依对象,甚至相依于 static 方法、.net framework 本身的对象(如 DateTime.Now)而导致无法测试的问题,还有另外一个方式,称为 fake object。这在后面的文章,会再进行较为详尽的介绍。

结论

以上几种用来测试的方式,希望对各位读者在不同情境下的设计,可以有所帮助。

而许多延伸的议题,在这系列文章并不会多谈,但在实务应用面上,却是相当重要的配套措施。例如一再提到的 DI framework,Repository Pattern,以及通过测试程序来说明对象的使用方式,请读者在现实设计系统时,务必了解这些东西如何让系统设计更加完整。

下一篇文章,将介绍怎么样可以避免每次手工敲打这么啰唆的 stub 对象,怎么针对 static 或 .net framework 本身的对象进行隔离,怎么针对对象与相依接口互动的情况进行测试。

原文链接:https://www.f2er.com/javaschema/285343.html

猜你在找的设计模式相关文章