問：在遺留代碼上面折騰單元測(cè)試是什么樣的體驗(yàn)明吩？
答：有時(shí)候構(gòu)造一個(gè)最簡(jiǎn)單的對(duì)象，給對(duì)象設(shè)最簡(jiǎn)單的值都會(huì)讓你崩潰殷费。印荔。低葫。
最近開始重構(gòu)一個(gè)項(xiàng)目的單元測(cè)試代碼，就有這種感覺仍律，廢話不多說嘿悬，先看一段測(cè)試代碼（注：為了不違反公司制度壹无，本文的所有代碼都是經(jīng)過加工過的代碼）
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);
}
}
這段測(cè)試代碼還是挺容易理解的云矫，輸入一個(gè)Charge（費(fèi)用）列表，輸出PaymentStatus（支付狀態(tài)）啃奴。不管3721草则，運(yùn)行一下再說钢拧，測(cè)試通過，今天運(yùn)氣真不錯(cuò)：）
測(cè)試雖然通過了炕横，但是有兩個(gè)問題娶靡，第一個(gè)問題是準(zhǔn)備Charge的代碼稍許有些重復(fù)，可以抽取一個(gè)方法用來構(gòu)造Charge對(duì)象看锉，方法有兩個(gè)參數(shù)姿锭，一個(gè)是total（總費(fèi)用），一個(gè)是paid（已付費(fèi)用）伯铣，代碼如下呻此，
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);
}
}
改完代碼，立刻運(yùn)行測(cè)試腔寡，順利通過焚鲜，第一個(gè)問題解決。第二個(gè)問題比較嚴(yán)重放前，運(yùn)行一個(gè)測(cè)試等了10s左右忿磅！
速度是檢驗(yàn)單元測(cè)試的唯一標(biāo)準(zhǔn)!
一個(gè)10s級(jí)別的單元測(cè)試是完全不可接受的，于是開始檢查慢的原因凭语，發(fā)現(xiàn)問題出在了BaseTestCase
public class BaseTestCase {
@BeforeClass
public static void before() {
loadFwConfig();
initDBConnection();
}
}
原來時(shí)間都花在初始化配置和數(shù)據(jù)庫(kù)連接上了葱她，而測(cè)試代碼并不需要讀取配置和數(shù)據(jù)庫(kù)訪問，于是立馬把extends BaseTestCase去掉似扔，運(yùn)行測(cè)試吨些，立馬報(bào)錯(cuò)，代碼果然不是說刪就能刪的炒辉。
java.lang.ExceptionInInitializerError
at com.goldtalent.DomainObjectRoot.notifyChange(DomainObjectRoot.java:242)
at com.goldtalent.Charge.setTotal(Charge.java:17)
靠豪墅，set方法也能報(bào)錯(cuò)！看了一下setTotal方法黔寇，問題出在this.notifyChange()上面偶器，notifyChange()是父類DomainObjectRoot（來自我司最著名的框架之一，但是對(duì)單元測(cè)試極不友好）的方法，需要訪問數(shù)據(jù)庫(kù)屏轰，剛才把初始化數(shù)據(jù)庫(kù)連接的代碼去掉了颊郎，所以出錯(cuò)。
public class Charge extends DomainObjectRoot {
public void setTotal(Double total) {
this.total = total;
this.notifyChange();
}
}
怎么才能不運(yùn)行this.notifyChange()這行代碼呢亭枷？當(dāng)然是用Mock大法（推薦mockito框架）袭艺，在運(yùn)行測(cè)試之前把它mock掉，測(cè)試代碼如下叨粘，
public class PaymentStatusTest {
@BeforeClass
public static void before() {
new MockUp<DomainObjectRoot>() {
@Mock
public void notifyChange() {
//哈哈猾编，這下你訪問不了數(shù)據(jù)庫(kù)了吧！
}
};
}
｝
這下應(yīng)該沒問題了吧升敲，再運(yùn)行測(cè)試答倡，靠，一波還未平息驴党，一波又來侵襲瘪撇，又報(bào)錯(cuò)！
java.lang.ExceptionInInitializerError
at com.goldtalent.DBUtils.getEntityManager(DBUtils.java:17)
at com.goldtalent.PaymentStatusConst.getObj(PaymentStatusConst.java:33)
暈港庄，get方法也需要連數(shù)據(jù)庫(kù)倔既！看到這里你會(huì)發(fā)現(xiàn)我司的單元測(cè)試是多喜歡連數(shù)據(jù)庫(kù)啊。讓我們一起看看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方法會(huì)根據(jù)id到數(shù)據(jù)庫(kù)里面把對(duì)應(yīng)的PaymentStatus對(duì)象查出來鹏氧。
那么怎么才能不調(diào)用PaymentStatusConst.getObj()呢渤涌？還是用Mock大法嗎？這里留個(gè)讀者自己思考一下把还，看看Mock是否可行实蓬？
我用了另外一種方法，其實(shí)吊履，PaymentStatusConst和PaymentStatus是一一對(duì)應(yīng)的安皱，測(cè)試代碼完全可以只比較PaymentStatusConst，但是要先重構(gòu)產(chǎn)品代碼艇炎，把PaymentStatusCalculator.calculate(charges)拆成2個(gè)方法酌伊，把討厭的getObj方法扔進(jìn)另外一個(gè)傻瓜的不需要測(cè)試的方法中，代碼如下：
public static PaymentStatusConst calculatePaymentStatusConst(List<Charge> charges) {
//這里省略計(jì)算總費(fèi)用和總支付費(fèi)用的邏輯
if (paidAmount == 0) {
return PaymentStatusConst.NONE;
if (paidAmount - totalAmount >= 0) {
return PaymentStatusConst.FULLY_PAID;
}
return PaymentStatusConst.PARTIAL_PAID;
}
//這個(gè)方法簡(jiǎn)單到?jīng)]邏輯冕臭，所以不用測(cè)試
public static PaymentStatus calculate(List<Charge> charges) {
return calculatePaymentStatusConst(charges).getObj();
}
重構(gòu)完的測(cè)試代碼如下:
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);
}
}
改完代碼，運(yùn)行測(cè)試辜贵，通過而且只用了0.53s，到此終于折騰完畢归形。
回顧下這次重構(gòu)托慨，主要經(jīng)歷了下面幾個(gè)步驟，
- 運(yùn)行測(cè)試暇榴，讓測(cè)試通過厚棵。
- 消除明顯的重復(fù)蕉世，讓代碼更少更清晰。
- 利用Mock繞過讓單元測(cè)試變慢的代碼婆硬。
- 很難Mock的時(shí)候狠轻，通過重構(gòu)生產(chǎn)代碼繞過讓測(cè)試變慢的代碼。
- 運(yùn)行測(cè)試彬犯，驗(yàn)證你的改動(dòng)向楼。
寫出真正的單元測(cè)試不容易，你是否也曾經(jīng)碰到過重重的障礙谐区？不要放棄湖蜕，相信我們終將能馴服單元測(cè)試。
