问：在遗留代码上面折腾单元测试是什么样的体验？
答：有时候构造一个最简单的对象，给对象设最简单的值都会让你崩溃。。。
最近开始重构一个项目的单元测试代码，就有这种感觉，废话不多说，先看一段测试代码（注：为了不违反公司制度，本文的所有代码都是经过加工过的代码）
public class PaymentStatusTest extends BaseTestCase {
@Test
public void testPaymentStatus() {
List<Charge> charges = Lists.newArrayList();
Charge c1 = new Charge();
c1.setTotal(100.0);
c1.setPaid(50.0);
charges.add(c1);
Charge c2 = new Charge();
c2.setTotal(100.0);
c2.setPaid(100.0);
charges.add(c2);
PaymentStatus status = PaymentStatusCalculator.calculate(charges);
assertEquals(PaymentStatusConst.PARTIAL_PAID.getObj(), status);
}
}
这段测试代码还是挺容易理解的，输入一个Charge（费用）列表，输出PaymentStatus（支付状态）。不管3721，运行一下再说，测试通过，今天运气真不错：）
测试虽然通过了，但是有两个问题，第一个问题是准备Charge的代码稍许有些重复，可以抽取一个方法用来构造Charge对象，方法有两个参数，一个是total（总费用），一个是paid（已付费用），代码如下，
public class PaymentStatusTest extends BaseTestCase {
@Test
public void testPaymentStatus() {
List<Charge> charges = Lists.newArrayList();
charges.add(createCharge(100, 50));
charges.add(createCharge(100, 100));
PaymentStatus status = PaymentStatusCalculator.calculate(charges);
assertEquals(PaymentStatusConst.PARTIAL_PAID.getObj(), status);
}
}
改完代码，立刻运行测试，顺利通过，第一个问题解决。第二个问题比较严重，运行一个测试等了10s左右！
速度是检验单元测试的唯一标准!
一个10s级别的单元测试是完全不可接受的，于是开始检查慢的原因，发现问题出在了BaseTestCase
public class BaseTestCase {
@BeforeClass
public static void before() {
loadFwConfig();
initDBConnection();
}
}
原来时间都花在初始化配置和数据库连接上了，而测试代码并不需要读取配置和数据库访问，于是立马把extends BaseTestCase去掉，运行测试，立马报错，代码果然不是说删就能删的。
java.lang.ExceptionInInitializerError
at com.goldtalent.DomainObjectRoot.notifyChange(DomainObjectRoot.java:242)
at com.goldtalent.Charge.setTotal(Charge.java:17)
靠，set方法也能报错！看了一下setTotal方法，问题出在this.notifyChange()上面，notifyChange()是父类DomainObjectRoot（来自我司最著名的框架之一，但是对单元测试极不友好）的方法，需要访问数据库，刚才把初始化数据库连接的代码去掉了，所以出错。
public class Charge extends DomainObjectRoot {
public void setTotal(Double total) {
this.total = total;
this.notifyChange();
}
}
怎么才能不运行this.notifyChange()这行代码呢？当然是用Mock大法（推荐mockito框架），在运行测试之前把它mock掉，测试代码如下，
public class PaymentStatusTest {
@BeforeClass
public static void before() {
new MockUp<DomainObjectRoot>() {
@Mock
public void notifyChange() {
//哈哈，这下你访问不了数据库了吧！
}
};
}
｝
这下应该没问题了吧，再运行测试，靠，一波还未平息，一波又来侵袭，又报错！
java.lang.ExceptionInInitializerError
at com.goldtalent.DBUtils.getEntityManager(DBUtils.java:17)
at com.goldtalent.PaymentStatusConst.getObj(PaymentStatusConst.java:33)
晕，get方法也需要连数据库！看到这里你会发现我司的单元测试是多喜欢连数据库啊。让我们一起看看PaymentStatusConst
public class PaymentStatusConst {
private long id;
public PaymentStatusConst(long id) {
this.id = id;
}
public PaymentStatus getObj() {
EntityManager em = DBUtils.getEntityManager();
return (PaymentStatus) em.find(PaymentStatus.class, this.id);
}
｝
PaymentStatusConst.getObj方法会根据id到数据库里面把对应的PaymentStatus对象查出来。
那么怎么才能不调用PaymentStatusConst.getObj()呢？还是用Mock大法吗？这里留个读者自己思考一下，看看Mock是否可行？
我用了另外一种方法，其实，PaymentStatusConst和PaymentStatus是一一对应的，测试代码完全可以只比较PaymentStatusConst，但是要先重构产品代码，把PaymentStatusCalculator.calculate(charges)拆成2个方法，把讨厌的getObj方法扔进另外一个傻瓜的不需要测试的方法中，代码如下：
public static PaymentStatusConst calculatePaymentStatusConst(List<Charge> charges) {
//这里省略计算总费用和总支付费用的逻辑
if (paidAmount == 0) {
return PaymentStatusConst.NONE;
if (paidAmount - totalAmount >= 0) {
return PaymentStatusConst.FULLY_PAID;
}
return PaymentStatusConst.PARTIAL_PAID;
}
//这个方法简单到没逻辑，所以不用测试
public static PaymentStatus calculate(List<Charge> charges) {
return calculatePaymentStatusConst(charges).getObj();
}
重构完的测试代码如下:
public class PaymentStatusTest extends BaseTestCase {
@Test
public void testPaymentStatus() {
List<Charge> charges = Lists.newArrayList();
charges.add(createCharge(100, 50));
charges.add(createCharge(100, 100));
PaymentStatusConst status = PaymentStatusCalculator.calculatePaymentStatusConst(charges);
//getObj()消失了，哈哈
assertEquals(PaymentStatusConst.PARTIAL_PAID, status);
}
}
改完代码，运行测试，通过而且只用了0.53s，到此终于折腾完毕。
回顾下这次重构，主要经历了下面几个步骤，
- 运行测试，让测试通过。
- 消除明显的重复，让代码更少更清晰。
- 利用Mock绕过让单元测试变慢的代码。
- 很难Mock的时候，通过重构生产代码绕过让测试变慢的代码。
- 运行测试，验证你的改动。
写出真正的单元测试不容易，你是否也曾经碰到过重重的障碍？不要放弃，相信我们终将能驯服单元测试。
