可能说到这里，你依然无法理解，代码被重构后解耦了，但这跟可测试性又有多大的关系呢？很遗憾的是目前因为有个很重要的概念还没能介绍，在这里只能简单的提及，那就是Mock Object，将会在后面的章节详细介绍，这里先简单带过。所谓Mock Object其实就是个假对象，但它只是模拟一个对象中某个/些方法，输入某些参数，返回一个预先设定的值，不用真的去执行代码。这样在做单元测试的时候，我们可以给Testability类实例的CalcService属性设置一个Mock Object， 然后在我们测试其中的ComplexCompute方法的时候，我们可以保证里面的用到的CalcService方法都按照我们期望并设定的方式执行（返回的值），从而实现：我们测试Testability类中的ComplexCompute方法的时候，不会再担心CalcServiceWraper类的实现是否存在错误，或者发生什么问题，因为在ComlexCompute中执行的是Mock Object，而不是真正的CalcServiceWraper对象。我们的单元测试于是就只是测试ComplexCompute方法，不再涉及其他方法！
非可测试性场景Untestable Scene
上一段提到的是依赖倒置是最正规的符合Testability的代码模式，但实际应用中，我们可能无法做到完全很好的执行，但有几种场景我们是必须要特别注意并避免的。
1. 静态变量
静态变量是非常不符合Testability要求的（但在处理遗留系统Legacy System时会有特别的用处，后文会提及）。
首先来看静态变量，因为静态变量是全局性的，而且是保持有状态的。在单元测试培训系列：（一）单元测试概念以及必要性中，我们有说过，单元测试是测试的最小单位，必须可信任的，可重复执行的。因此，若使用静态变量，就会导致破坏单元测试的可重复执行性，并且可能干扰到别的单元测试方法。
例如：在方法A中改变了全局静态变量StaticVariableA的值，而在方法B中又要去尝试读取这个静态变量的值，那么在单元测试执行的过程中，若执行方法A和方法B的单元测试方法顺序不同，或执行多次很可能每次结果都会不同，这样明显会导致我们的单元测试结果不再可信。因此，我们应该尽量避免静态变量的使用。
2. 静态方法
静态方法的可测试性不强的原因倒不是因为静态方法自身有什么太大的问题，而是在编写单元测试的过程中受制于工具框架的限制：目前的开源Mocking Framework中都不支持对静态方法进行模拟，若大量使用静态方法，会在编写单元测试的时候遇到无法解耦的问题。当然利用一些商业Mocking Framework，如TypeMock，Moles等可以规避这个问题。
除了静态方法外，因为同样的开源Mocking Framework项目的限制，sealed类也是可测试性很差的代码。具体原因，我们放到后面的Mock Object章节一起介绍。
3. 直接依赖外部环境
一般来说，单元测试是要求代码尽可能不直接依赖于I/O文件接口，数据库，网络环境甚至系统环境（如时间等），但实际上一个项目总会有一部分代码无可避免的需要去访问这些外部资源，但我们可以尽量的控制这些代码集中在较小的范围内，并通过提取接口的方式使其他代码和这些直接访问外部资源的代码之间解耦。
因此，泛滥的在代码中随意使用访问外部资源的代码是非常Untestable的设计，例如：在程序中到处都是访问数据库的代码，DataContext出现在每层代码中；到处充满依赖于ASP.NET或者WCF环境的代码（HttpContext， HttpRequest等）。
我们没办法实现对边界代码的单元测试，只能通过集成测试来检验，例如对数据库访问层代码的测试；对网络访问层代码的测试等。但我们必须尽可能的防止这些边界代码的扩散，要尽可能的使他们被隔离起来。这个问题因为涉及面很广，暂不展开说明，在接下来的篇幅中会专门针对Entity Framework和ASP.NET MVC的Testability进行优化分析。
相关链接：
