public class XmlConvert
   {
       protected virtual string ConvertReplace(StringBuilder NodeString)
       {
           return NodeString.ToString().Replace("XXX", "LLL");
       }
   }

有一个很简单的XmlConvert类，是框架内部使用的，现在它提供了一个Virtual方法ConvertReplace，我们想使用这个框架内部的类进行扩展；

public class CustomerXmlConvert : XmlConvert
{
    protected override string ConvertReplace(StringBuilder NodeString)
    {
        return base.ConvertReplace(NodeString).Replace("JJJ", "AAA");
    }
}

但是如果未能提供给我们一个多态入口，我们这个自定义的CustomerXmlConvert无法起作用；最近发现很多自定义的框架设计上就有这个问题，留有了扩展的类型和相应的方法，但是无法插入到框架内部去，所以特此分享一下；

4】多态的受保护方法的单元测试

受保护方法的单元测试一直都不太好解决，但是我们可以通过简单的继承方式来轻松的处理，就拿上面提到的XmlConvert类来举例；

public class XmlConvert
{
    protected virtual string ConvertReplace(StringBuilder NodeString)
    {
        return NodeString.ToString().Replace("XXX", "LLL");
    }
}

如果我们想测试它，直接使用类型继承就可以：

[TestClass]
public class XmlConvertTests : XmlConvert
{
    [TestMethod]
    public void XmlConvert_ConvertReplace_Normal()
    {
        StringBuilder testData = new StringBuilder("XXXJJJ");
        string testResult = this.ConvertReplace(testData);
        Assert.AreEqual(testResult, "JJJ");
    }
}

这里有一个很好的设计启发就是将方法碎片化尽量保持有返回值的操作，这样很好的进行Assert；其实提到单元测试，冥冥之中总觉得它与面向对象有着一脉相承的感觉，甚至单元测试、重构、面向对象都会起到互补的作用；

内容不多，只是简单的项目小小的总结，希望对大家有用，谢谢；

作者：王清培