应用设计模式编写易于单元测试的代码

发布: 2009-12-24 14:09 | 作者: 不详 | 来源: 领测国际测试网采编 | 查看: 23次 | 进入软件测试论坛讨论

private static CacheFactoryinstance = new DelegateCacheFactory(); private static CacheFactorydelegate; protected CacheFactory() { } // CacheFactory is a singletonpublic static CacheFactory getInstance() { return instance; } // the implementation can be changedprotected static void setDelegate(CacheFactory instance) { delegate= instance; } public abstract Cache getCache(Object... args); // redirect all request to delegateeprivate static class DelegateCacheFactoryextendsCacheFactory { private DelegateCacheFactory() { } public Cache getCache(Object... args) { return delegate.getCache(args); } } }

　　与 CacheFactoryImpl 类似地，我们实现了一个 MockCacheFactory，但与 CacheFactoryImpl 不同的是，这个 MockCacheFactory 所创建的 MockCache 对象虽然与真正的 Cache 实现了相同的接口，但是，它的内部实现却是基于 HashMap 的，因此，可以很好地满足单元测试快速、方便地运行的需要。

　　单元测试时，只需要在 setUp 时调用执行如下操作：

setDelegate(new MockCacheFactory());

　　将 CacheFactory 的实现委托给 MockCacheFactory 即可，所有业务逻辑都无需作任何修改，因此，这种替换实现的方式几乎是没有侵入性的。

　　这种通过将实现分离到专门的实现类中的做法其实是 Bridge 模式的一个应用，通过使用 Bridge 模式，为替换实现保留了接口，从而使得在不对业务逻辑作任何修改的情况下可以轻松替换公共服务的实现。

　　除此之外，Strategy 模式也是一种替换实现的有效途径，这种方式与 Factory Method 类似，通过子类化实现新的 Strategy 以替换业务逻辑使用的旧的 Strategy，通过与 Factory Method 或 Bridge 等模式联合使用，在编写应用公共服务的业务逻辑的单元测试时也十分有用。

　　绕过部分实现

　　绕过部分实现进行单元测试在大多数情况下是不可取的，因为这种做法极有可能会影响单元测试的质量。但是对于一些特殊的情况，我们可以“冒险”使用这种方式，比如有这样的一个场景：所有请求需经过多级认证，且部分认证处理需要访问数据库，认证结束后为请求分配相应的 sessionId，请求在获得 sessionId 后继续进行进一步的业务逻辑处理。