最近站會時，經常聽見開發人員說某Story已經開發完了，等待聯調，然后就沒有然后了。對于聯調時間點近的，開發人員會等一等，一天的時間很快就過去了；時間點遠的，開發就領新story了，等另一端開發完，已經若干天過去了。我總覺得其中有什么問題，但是說不出來。上周去QCon聽了韓老師的分享，突然發現這種聯調在以前團隊的也是有的。只不過我們的解決方式不一樣，所以問題沒有這么突出。

產生問題的原因很簡單，現在的軟件開發，因為系統復雜性提升，模塊拆分也很普遍，很難形成一個團隊做端到端交付，沒有任何外部依賴。典型場景是模塊A由一個團隊1開發，模塊B由團隊2開發。這時，團隊A的功能開發完成后必須要和團隊B開發的相應功能聯調。目的是走一個端到端的流程，確認功能正確。

問題也來了，

• 團隊1和團隊2的開發計劃多是獨立制定，很難做到同一功能在兩個模塊上同時開發完成，之間沒有任何等待。開發快的要等開發慢的，一方的story雖然開發完了，但不能進入測試，延長了交付時間。

• 等測試發現bug時，已經過去一兩天甚至更久，開發在做其他功能。回來解決問題，又要上下文切換，再度浪費時間。

• 同時聯調發生問題時，定位問題還需要花一番功夫。

之前的項目中我們使用一種契約測試(Contract Testing)的方法來解決這個問題。

• 首先，兩個團隊確定接口具體格式，這組格式就相當于一組契約，而后兩個團隊根據這個契約開發各自功能。

• 同時，作為消費方的團隊1為這個接口添加一組自動化測試，確保模塊B的功能符合契約。每次模塊B的代碼改動都會觸發這組測試，測試通過時意味著生產者為消費者提供了正確的功能，反之不能。這樣模塊B的改動肯定不會影響模塊A，即便有影響，也可以通過測試在第一時間反映出來。

這種方法，節省了開發人員的聯調時間，QA直接測試端到端的功能。同時遇到問題時也很容易定位問題產生根源。

這種測試與模塊A自身的單元測試不同，著眼點在確保模塊外部依賴的正確性。有了這層保障，模塊A的單元測試就可以使用Test Double(Fake、Mock等)，構造出更關注于自身邏輯的測試集，提高測試的運行速度和穩定性。

采用這種方法時有兩個問題需要考慮，

1. 誰來寫測試 - 這個回答相對簡單，一定要由消費者來寫，這樣才能確保測試代碼和產品代碼采用相同的調用方式。

2. 如何組織測試 - 有兩種方式可以選擇，放在消費者端，每個消費者維護自己的一套測試；或放在生產者一端，每個模塊維護一套針對本模塊的測試。第一種方式更容易引起相關消費者團隊的重視，針對性更強，但會引入一定的代碼重復，第二種正相反。為了更快更有針對性的發現問題，我所在的團隊使用了第一種方法。

在寫這個的時候，順便搜了一下，發現了老馬的這篇文章IntegrationContractTest，基本思想類似，實現上稍有不同。最后總結一下，手工聯調這種費時費力的工作，能少做就少做，能自動化就自動化，搞軟件的生命短暫，浪費在這上不值。

原文鏈接：http://www.ituring.com.cn/article/42460