软件代码在一些方面很像艺术品，各家的审美标准不同，对同一段代码的看法也就不一样。虽然有很多公认的设计模式和原则，但在具体应用上有时也是公说公有理，婆说婆有理。这里我分享一些通过编写测试得出的度量项目，通过测试代码中体现的问题反过来检查产品代码的问题。
一、枚举的规则意味着枚举的测试
if (CARREFOUR.equals(supplier)) {
return EUR;
} else if (CENTURY_MART.equals(supplier)) {
return CNY;
} else {
throw new UnsupportedSupplierException(supplier);
}
类似这样的条件分支语句非常常见，其测试也并不难，将每种条件都覆盖到即可
@Test
public void returnsEurWhenGetCurrenyGivenCarrefour() throws Exception {
assertEquals(EUR, target.getCurrencyBy(CARREFOUR));
}
@Test
public void returnsCnyWhenGetCurrenyGivenCenturyMart() throws Exception {
assertEquals(CNY, target.getCurrencyBy(CENTURY_MART));
}
@Test(expected=UnsupportedSupplierException.class)
public void throwsExceptionWhenGetCurrenyGivenUnknownSupplier() throws Exception {
target.getCurrencyBy(WE_DONT_KNOW);
}
如果现在要支持一个新的供应商，那么可以增加一个测试用例，然后在条件分支中增加一个else if来实现，也就是说每新增一个供应商，我们就得新增一个测试，如果这种变化的频率比较高（噢，这是好事，说明生意做得不赖），代码和测试就会显得比较笨拙。让我们改进一下代码：
final String currency = currencies.get(supplier);
if (currency != null) {
return currency;
} else {
throw new UnsupportedSupplierException(supplier);
}
由于使用了Map作为实现，测试分支是固定的了，和供应商的增减无关了。
@Before
public void setupTestFixture() {
Map currencies = new HashMap();
currencies.put(MATCHED, CORRESPONSED);
currencies.put(ANOTHER, ANOTHER_CURRENCY);
target.setCurrencies(currencies);
}
@Test
public void returnsCorresponsedCurrencyWhenSupplierNameMatched() throws Exception {
assertEquals(CORRESPONSED, target.getCurrencyBy(MATCHED));
}
@Test(expected=UnsupportedSupplierException.class)
public void throwsExceptionWhenGetCurrenyGivenUnknownSupplier() throws Exception {
target.getCurrencyBy(WE_DONT_KNOW);
}
二、静态方法对修改开放，对“测试”关闭
使用静态方法非常简单，无需实例化并传递对象，在哪里都可以直接使用，但如果过度依赖它们，在测试中就不好办了。
public boolean preHandle(HttpServletRequest request, HttpServletResponse response) {
if (SessionUtils.isUnexpired(request)) {
return true;
} else {
//在response中输出alert语句
}
}
由于在静态方法中对保存在session中的属性做了计算和校验，要对其进行测试就需要事先在session中填充很多信息。
@Test
public void returnTrueWhenUserSessionIsNotExpired() throws Exception {
MockHttpServletRequest request = new MockHttpServletRequest();
MockHttpSession session = new MockHttpSession();
request.setSession(session);
session.set......blablabla
assertTrue(target.preHandle(request));
}
@Test
public void printAlertAndreturnFalseWhenUserSessionIsExpired() throws Exception {
MockHttpServletRequest request = new MockHttpServletRequest();
MockHttpSession session = new MockHttpSession();
request.setSession(session);
session.set......blablabla
assertFalse(target.preHandle(request, response));
assertEquals(ALERT, response.getContentAsString());
}
由于静态方法属于类，无法通过子类化并覆写的方式在测试时替换，即使测试重点并非SessionUtils.isUnexpired(req)本身，但由于它是一个必经步骤，你不得不为其准备完整的测试数据（哪怕非常麻烦）。让我们对它改造一下吧，不过我也并不想再实现一次isUnexpired(req)，耍个小花招吧
再来看测试，就简单多了，我们可以用Stub/mock来替换SessionGateway的实现。
@Test
public void returnTrueWhenUserSessionIsNotExpired() throws Exception {
context.checking(new Expectations() {
{
allowing(sessionGateway).isUnexpired(request)；
will(returnValue(true));
}
});
assertTrue(target.preHandle(request, response));
}
@Test
public void printAlertAndreturnFalseWhenUserSessionIsExpired() throws Exception {
context.checking(new Expectations() {
{
allowing(sessionGateway).isUnexpired(request)；
will(returnValue(false));
}
});
assertFalse(target.preHandle(request, response));
assertEquals(ALERT, response.getContentAsString());
}
小插曲、测试版的为什么组合优于继承
你可能已经见过各种版本的组合优于继承的理论和实例，下面我贡献一个测试版本的 :D
先来看一下template版本的测试方案，我们需要分别对SubTemplate1和SubTemplate2的template()编写测试，并且由于AbstractTemplate的template()依赖SomeDependency和AnotherDependency，所以在以上两个测试中，我们需要使用Stub/Mock将它们替换掉，并为每一个测试准备一整套测试数据，即使它们的implementThis()方法只是return 1 和return 2。
再来看一下strategy版本的测试方案，我们需要为UsingStrategy编写测试，并用Stub/Mock替换Strategy、SomeDependency和AnotherDependency的实现，再分别为Strategy1、Strategy2编写测试。
你看，是不是strategy版本的测试方案的职责更清晰一些，每个测试都只负责被测试目标自己的代码，这种感觉在Template的子类特别多，Template包含的模板代码越是完整的时候越明显。
三、样板代码
有些代码吧，不管开发什么功能都要写的，比如经典的 service-dao，我们来看两个案例：
@Transactional （1）
@Override
public void cancel(String orderId) {
Order order = orderRepository.findBy(orderId); （2）
order.cancel();
orderRepository.store(order); （3）
}
@Transactional （4）
@Override
public void acknowledge(String orderId) {
Order order = orderRepository.findBy(orderId); （5）
order.acknowledge();
orderRepository.store(order); （6）
} 这段代码实现了两个功能，取消订单和确认订单，我们假设其逻辑非常简单，Order对象自己就可以处理，其中（2）、（5） 和 （3）、（6）是配对出现的，由于需要持久化数据，这两步总是免不了的。另外，比较隐蔽的是（1）、（4），这两行代码声明了事务，但很少有人去测试它们，而且经常会忘记添加它们。
@Test
public void orderIsCanceledAfterCancelling() throws Exception {
final Order order = new OrderFixture().build();
final String orderId = order.getId();
context.checking(new Expectations() {
{
allowing(orderRepository).findBy(orderId);
will(returnValue(order));
oneOf(orderRepository).store(order);
}
});
target.cancel(orderId);
assertTrue(order.isCanceled());
}
@Test
public void orderIsAcknowledgedAfterAcknowledging() throws Exception {
final Order order = new OrderFixture().build();
final String orderId = order.getId();
context.checking(new Expectations() {
{
allowing(orderRepository).findBy(orderId);
will(returnValue(order));
oneOf(orderRepository).store(order);
}
});
target.acknowledge(orderId);
assertTrue(order.isAcknowledged());
}
其实，这两段代码并没有什么分支，要大费周张地测试有些多余。最好能够在满足覆盖率的情况下只测试order，尽可能减少所谓的“service”。利用Command模式，将“service”压缩到一个。
@Test
public void orderIsCanceledAfterCancelling() throws Exception {
final Order order = new OrderFixture().build();
final CancelOrderCommand command = new CancelOrderCommand();
command.handle(order);
assertTrue(order.isCanceled());
}
@Test
public void orderIsAcknowledgedAfterAcknowledging() throws Exception {
final Order order = new OrderFixture().build();
final AcknowledgeOrderCommand command = new AcknowledgeOrderCommand();
command.handle(order);
assertTrue(order.isAcknowledged());
}
经过修改后，在测试中我们不用再编写样板代码（同时产品代码中也不用了），由于Order、Command都可以通过构造函数实例化, 测试场景的准备就简单了。而且@Transactional忘记添加的问题也有所缓解（因为只需要一个“service”了）
四、对应代码抽象级别的测试
public void run() {
loggingSupport.info("start running, productId=" + productId);
if (a) {
......
} else if (b) {
......
} else {
......
}
loggingSupport.info("end running, productId=" + productId);
} 在它的三个测试中，都需要特意指定一下日志记录的内容：
final String startText = "start running, productId" + productId;
final String endText = "end running, productId" + productId;
context.checking(new Expectations() {
{
oneOf(loggingSupport).info(startText);
// other expectations
oneOf(loggingSupport).info(endText);
}
});
target.run();
出现这种情况的一个原因就是抽象层级没有把握好，在run()方法中，应该是关注的流程，而不是流程节点的实现。比如你在一个测试中编写了很多的断言（对模拟对象的预期定义也可以看作是一种断言），就很有可能说明了这种现象，最好通过引入更细粒度的对象来分担职责。这里我们不妨引入RunnerNotifer，让它来通知记录日志：
public void run() {
runnerNotifier.notifyStart(productId);
if (a) {
......
} else if (b) {
......
} else {
......
}
runnerNotifier.notifyEnd(productId);
} 这样修改之后，测试代码就不需要再拼接日志内容了：
context.checking(new Expectations() {
{
oneOf(runnerNotifier).notifyStart(productId);
// other expectations
oneOf(runnerNotifier).notifyEnd(productId);
}
});
target.run();
然后再单独为RunnerNotifier的实现添加测试即可。
本次就到这里，如果你有更好的想法，请务必跟贴让我知道，谢谢 :)
