当我们面对一个遗留系统时，常见的问题是没有测试。正如Michael Feathers在Working Effectively with Legacy Code一书中对“遗留代码”的定义。他将其简单归纳为“没有测试的代码”。真是太贴切了！正是因为没有测试，使得我们对遗留代码的任何重构都有些战战兢 兢，甚至成为开发人员抵制重构的借口。从收益与成本的比例来看，对于这样的系统，我一贯认为不要盲目进行重构。因为重构的真正适用场景其实是发生在开发期 间，而非维护期间。当然，提升自己的重构能力，尤其学会运用IDE提供的自动重构工具，可以在一定程度上保障重构的质量。然而，安全的做法，还是需要为其 编写测试。
测试是分层的，即使是针对自动化测试。面对遗留系统，成本相对较低的是针对功能特性编写的功能测试（或者说是验收测试），这可以运用一些BDD框架 如Cucumber、JBehave等。由于它的测试粒度较粗，可以以较少的测试用例覆盖系统的主要功能。然而，它的缺点同样存在，那就是反馈周期相对较 长。这就好像你置身一个陌生的城市，在找不到路的情况下，只是跟着感觉走。走了数十公里之后，方才幡然醒悟，想起要翻一翻带在手上的地图。倘若发现方向走 错，再要回转就已经晚了。反馈周期最短的自然是单元测试。同样根据Michael Feather的定义，单元测试一定要快，一定要不依赖于外部资源。单元测试的粒度自然是最小的，但不要直观地认为单元测试就是针对方法。若只是针对方法 来编写单元测试，就会陷入为测试而测试的怪圈。即使是位于技术象限的单元测试，我们仍然要按照业务规则来编写。一个测试方法应该对应一个粒度最小的原子功 能。
要让单元测试跑得快，还要不吃草（依赖外部资源），应该怎么办？答案呼之欲出，那就是Mock。Mock当然不是万能的，记得胡凯写过一篇文章，提 及Mock不是银弹。我知道他仅仅是为了强调这个观点，避免太多人过于依赖Mock，因为Brooks早就发表过论断，在软件行业，其实根本就“没有银 弹”。关于Mock的争论由来已久，对此，我准备避而不谈。至少在我看来，如下几点基本已成定论：
1、是Mock行为，而非Mock数据；如果是针对数据，则应该属于Stub的范畴；
2、Mock通常发生在三种情况（让我们假设被测试对象为消费者，它要协作的对象为服务，此时需要Mock服务）：服务的行为只有定义，还未实现； 服务需要访问外部资源（这意味着它可能很慢，也意味着它需要依赖外部资源）；服务的行为结果不确定（例如天气服务，股票服务）。
自然，我们不需要自己写Mock，有许多现成的好用框架，例如Java平台下的Mockito与EasyMock，.NET平台下的Moq，以及C++下的Google Mock和MockCpp。
然而，问题依然存在。考虑这样两种情况：
1、当我们要Mock的服务，其实是Utils的静态方法时，应该怎么办？
2、当我们要测试的方法内部直接实例化了协作的服务对象，又该怎么办？
显然，这是设计和代码的坏味道，它明显违背了DIP原则，即它不应该依赖于细节，而应该依赖于抽象。换言之，它产生了对服务对象的具体依赖。若要遵循DIP，就应该在被测对象的外部来注入依赖。这种紧耦合酿成了我们设计的类不具备良好的可测试性。
一个蠢蠢欲动的声音在说：让我们重构吧！且住，先让我们把这苛求的眼光放柔和一点。当你视所有丑陋的代码为“蝼蚁”时，那是因为你站在了足够的高 度。可是站得太高，往往摔得更惨。现在，还是脚踏实地，先设身处地地考虑这样的场景：这是一个代码行数超过1000万行的软件系统，一共有十余个开发团 队，一百多名开发人员在这个团队中工作。这个系统几乎没有测试，而系统的Jar包则达到上千个。这些Utils的静态方法被数十乃至上百个类调用，牵涉到 的模块也有多个甚至十余个。而且，这个系统并没有引入任何一个IoC容器。有了这样一个背景，让我们再把柔和的眼光变得锐利一点，分析分析重构的可行性。 要消除前面提到的坏味道，就需要将这些静态方法修改为实例方法，并通过依赖注入的方式注入。这个变化带来的是对整个系统的全局影响，即使我们有一些自动化 重构的手段，仍然不认为这种重构一定就是可行的。
这就是我要谈PowerMock的前提！
现在，轮到玩花招的PowerMock出场了。有了它，什么静态方法，方法内部实例，乃至私有方法，统统都是浮云。而且，它对Mockito与 EasyMock的扩展，使得我们更容易熟悉它的语法。要使用它很简单，需先设置对它的依赖。我选择了PowerMock针对Mockito的扩展：
<dependency> <groupId>org.powermock</groupId> <artifactId>powermock-api-mockito</artifactId> <version>1.5.1</version> </dependency> <dependency> <groupId>org.powermock</groupId> <artifactId>powermock-module-junit4</artifactId> <version>1.5.1</version> </dependency> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-all</artifactId> <version>1.9.5</version> </dependency>
|
让我先给出如下的一份奇奇怪怪的设计，它主要是为了迎合之前提到的代码臭味。
public class EmployeeTableUtil { public int count() { return 0; } public static final List<Employee> findAll() { return new ArrayList<Employee>(); } public void insert(Employee employee) { if (existed(employee.getId())) { throw new ExistedEmployeeException(); } //insert employee } public static final void update(Employee employee) { if (employee == null) { throw new NullEmployeeException(); } } public boolean delete(Employee employee) { if (existed(employee.getId())) { //delete employee return true; } return false; } private boolean existed(String id) { return false; } } public class EmployeeRepository { private EmployeeTableUtil tableUtil; public int count() { return new EmployeeTableUtil().count(); } public List<Employee> findAll() { return EmployeeTableUtil.findAll(); } public boolean insert(Employee employee) { try { tableUtil.insert(employee); return true; } catch (ExistedEmployeeException e) { return false; } } public boolean update(Employee employee) { try { EmployeeTableUtil.update(employee); return true; } catch (NullEmployeeException e) { return false; } } public boolean delete(Employee employee) { return tableUtil.delete(employee); } private double bonus(Employee employee) { return employee.getSalary() * 0.1d; } public void setTableUtil(EmployeeTableUtil tableUtil) { this.tableUtil = tableUtil; } }
|
现在，我要针对EmployeeRepository编写测试，它协作的服务类为EmployeTableUtil，主要承担了访问数据库的职责。在测试EmployeeRepository时，我们需要去Mock协作对象EmployeeTableUtil的行为。
在使用PowerMock编写测试时，首先需要在测试类上运用框架提供的Annotation：@PrepareForTest，以及一个 Runner：PowerMockRunner。因为我们要Mock的对象为EmployeeTableUtil，故而测试类的定义为：
@RunWith(PowerMockRunner.class) @PrepareForTest(EmployeeTableUtil.class) public class EmployeeRepositoryTest { private EmployeeRepository repository; @Before public void setUp() throws Exception { repository = new EmployRepository(); } }
|
现在我要使用PowerMock去Mock静态方法，如EmployeeTableUtil的findAll()方法，至于要测试的方法则为EmployeeRepository的findAll()方法。则编写的单元测试为：
@Test public void should_mock_static_method() { List<Employee> employee = new ArrayList<Employee>(); employee.add(new Employee("1")); employee.add(new Employee("2")); PowerMockito.mockStatic(EmployeeTableUtil.class); when(EmployeeTableUtil.findAll()).thenReturn(employee); List<Employee> employees = repository.findAll(); assertThat(employees.size(), is(2)); assertThat(employees.get(0).getId(), is("1")); assertThat(employees.get(1).getId(), is("2")); PowerMockito.verifyStatic(); EmployeeTableUtil.findAll(); }
|
Mock静态方法的关键是先要调用框架定义的PowerMockito类的mockStatic()方法（针对EasyMock有相似的类）。方法 接收的参数就是我们要Mock的类的类型。接下来就可以调用Mockito框架的方法，对我们要模拟的方法findAll()进行模拟，这里主要的工作是 为模拟方法的返回值设置一个stub。之后就是单元测试的验证逻辑。如果需要验证被Mock的方法是否被调用，则需要调用 PowerMockito.verifyStatic()方法，紧随其后的是被mock的方法。
如果要Mock的方法是一个命令方法（即没有返回值的方法），做法又有不同。倘若熟悉Mockito，可以看出PowerMock完全沿袭了Mockito的风格（当然，针对EasyMock的扩展则会沿袭EasyMock的风格，这是PowerMock体贴人的地方）：
@Test public void should_mock_exception_for_command_method_in_mock_object() { Employee employee = new Employee("1"); PowerMockito.mockStatic(EmployeeTableUtil.class); PowerMockito.doThrow(new NullEmployeeException()).when(EmployeeTableUtil.class); EmployeeTableUtil.update(employee); assertThat(repository.update(employee), is(false)); }
|
PowerMock还可以Mock私有方法，当然只能是实例的私有方法。这主要发生在当我们不希望Mock服务的公开方法时（例如，公开方法的逻辑 没有Mock的必要），但这些公开方法的内部又调用了自己的私有方法，而私有方法却需要Mock。例如，EmployeeTableUtil的 insert()和delete()方法调用了私有的existed()方法。假设insert()和delete()方法不需要我们Mock，此时就需 要对私有方法existed()进行Mock。因为是实例方法，所以下面的测试方法通过调用setTableUtil()方法将被模拟的对象注入到 EmployeeRepository对象中：
@Test public void should_mock_private_method() throws Exception { Employee employee = new Employee("1"); EmployeeTableUtil util = PowerMockito.spy(new EmployeeTableUtil()); PowerMockito.when(util,"existed", anyString()) .thenReturn(true); repository.setTableUtil(util); assertThat(repository.insert(employee), is(false)); assertThat(repository.delete(employee), is(true)); }
|
PowerMock顺带还提供了测试私有方法的便捷办法（注意是测试，而不是Mock）。例如，测试EmployeeReployee类的私有方法bonus()：
@Test public void should_test_private_method() throws Exception { Employee employee = new Employee("1"); employee.setSalary(8000); double result = Whitebox.<Double>invokeMethod(repository, "bonus", employee); assertThat(result, is(800d)); }
|
最后再来看看另外一种诡异的手段。假设我们要测试的方法其内部调用了协作对象的方法，而该协作对象不是在外部注入的，而是在方法中直接实例化。例如在前面例子中，EmployeeRepository的count()方法：
public class EmployeeRepository { private EmployeeTableUtil tableUtil; public int count() { return new EmployeeTableUtil().count(); } }
|
要针对这样一种情形进行Mock，做法有所不同。因为它实际针对的是待测类——即这里的EmployeeRepository——执行 count()方法，这就需要在count()方法内部形成一个拦截点。因此，需要在@PrepareForTest标记中指向 EmployeeRepository类的类型，而非我们要Mock的EmployeeTableUtil。故而，我们需要为这个测试定义一个新的测试 类：
@RunWith(PowerMockRunner.class) @PrepareForTest(EmployeeRepository.class) public class ConstructionEmployeeRepositoryTest { @Test public void should_mock_construction_object() throws Exception { EmployeeTableUtil util = mock(EmployeeTableUtil.class); when(util.count()).thenReturn(100); PowerMockito.whenNew(EmployeeTableUtil.class).withNoArguments().thenReturn(util); EmployeeRepository repository = new EmployeeRepository(); assertThat(repository.count(), is(100)); } }
|
注意，测试方法的前两行代码调用的mock()与when()方法都是Mockito提供的方法，与PowerMock无关。
我虽然没有看过PowerMock的源代码，但我猜测，当我们在使用PowerMock去Mock静态方法时，定然是结合反射与代理的方式来完成对 该方法的调用，其中必然需要初始化该类。由于是静态方法，更多的是需要静态初始化。此外，还有一种情形时，你所要测试的类声明和初始化了一个静态的字段。 这些都可能需要调用静态初始化。我们在开发中就碰到一种情形是，我们希望Mock的一个类，定义了一个static块，其中又调用了私有的静态方法。在这 个私有静态方法中，依赖了其他的一些对象，这些对象还牵扯到服务容器的问题。即使以静态的方式Mock了该类，仍然逃不过运行static块的命运，换言 之，仍然需要依赖服务容器。这时，又可以祭出PowerMock的杀器了。它提供了@SuppressStaticInitializationFor的 标注，在该标注中需要传入字符串类型的目标类型的全名。假设EmployeeTableUtil有一个static块是我们需要绕过的，它的类全名为 com.agiledon.powermock.EmployeeTableUtil：
@RunWith(PowerMockRunner.class) @PrepareForTest(EmployeeTableUtil.class) @SuppressStaticInitializationFor("com.agiledon.powermock.EmployeeTableUtil") public class EmployeeRepositoryTest {}
|
此外，对于@PrepareForTest以及@SuppressStaticInitializationFor标记而言，如果需要针对多个类型，则需要传入一个数组，例如：
@RunWith(PowerMockRunner.class) @PrepareForTest({MockedObjectA.class, MockObjectB.class}) @SuppressStaticInitializationFor({"com.agiledon.powermock.MockedObjectA", "com.agiledon.powermock.MockedObjectB"}) public class OneTest {}
|
或许我已经变得像祥林嫂一般的唠叨，但我还是必须再次申明，以上Mock方式所针对的情形皆为设计与代码的坏味道。优先情况下，我们应该重构，使得 它遵循DIP原则，解除对服务类的耦合，使其具有良好的可测试性；而不能因为有了强大的PowerMock而“姑息养奸”。换言之，让我们仅仅将 PowerMock耍弄的种种花招，看做是压箱底的手段。实在走投无路了，再祭出你的杀手锏吧！
