前后分離　

　　前后端分離已經是業界所共識的一種開發/部署模式了。所謂的前后端分離,是指后端開發人員只需要定義出接口就可以了，而不需要在編寫jsp等東西,而前端開發人員也只需要專心做界面，需要數據的地方直接調用后端開發人員定義的就行了。 　　這樣，前后端就分別有了著自己的開發流程，構建工具，測試等。做前端的誰也不會想要用Maven或者Gradle作為構建工具，同樣的道理，做后端的誰也不會想要用Grunt或者Gulp作為構建工具。前后端僅僅通過接口來協作，這個接口可能是JSON格式的RESTFul的接口，也可能是xml的，重點是后臺只負責數據的提供和計算，而完全不處理展現。而前端則負責拿到數據，組織數據并展現的工作。這樣結構清晰，關注點分離，前后端會變得相對獨立并松耦合?！?　　但有一個很頭痛的問題。比如在最后需要集成的時候，我們才發現最開始商量好的數據結構發生了變化，而且這種變化往往是在所難免的，比如:deliveryAddress字段本來是一個字符串，現在變成數組了（業務發生了變更，系統現在可以支持多個快遞地址）；PRice字段變成字符串，協商的時候是number；用戶郵箱地址多了一個層級等等。這些變動在所難免，而且時有發生，這會花費大量的調試時間和集成時間，更別提修改之后的回歸測試了。 　　歸根結底，還是前端或者后端感知到變化的時間周期太長，不能“及時協商，盡早解決”，最終導致集中爆發。怎么解決這個問題呢？我們需要提前協商好一些契約，并將這些契約作為可以被測試的中間產品，然后前后端都通過自動化測試來檢驗這些契約，一旦契約發生變化，測試就會失敗。這樣，每個失敗的測試都會驅動雙方再次協商，有效的縮短了反饋周期，并且降低集成風險。

Swagger

　　Swagger(http://swagger.io/docs/)主要提供了三個功能，Swagger Editor,Swagger Codegen,Swagger UI分別是編輯器，代碼生成器以及API文檔界面。 　　在Swagger Editor中，我們可以基于YAML語法定義我們的RESTful API，然后它會自動生成一篇排版優美的API文檔，并且提供實時預覽。使用Swagger Codegen能夠自動生成Mock server所需要的代碼，這樣一來前端開發就再也不用等著后端API 的實現了。除此之外，它還有一個更強大的功能，甚至能夠幫助我們自動生成不同語言的客戶端的代碼。Swagger是基于插件來實現各種不同的語言的，所以，如果已經提供的語言中沒有你正在用的，你也可以自己實現相應的插件，甚至是從源代碼級別進行定制化。

契約測試

　談到了前后端分離，那么在所難免，會遇到一些集成的問題：一撥人在全心全意的進行前端開發，另一撥人在心無旁騖的做后端開發，那么誰應該為集成買單呢？在現在這個持續集成、持續交付的年代里，我們應該如何去保證雙方不會分道揚鑣、越走越遠呢？ 　 所以，在一開始就定一個契約就成了迫在眉睫的事情，雙方就API相關的內容，包括路徑、參數、類型等達成一致，當然，這份契約并不是一旦創建就不能修改的，而且，如果一開始沒有設計好，很有可能會頻繁的修改。這個時候，要讓雙方都能夠實時的跟蹤最新的API就成了一個難題。還好，有了Swagger后，我們可以方便的做契約測試。 　 簡而言之，我們需要商定一些契約，并將這些契約作為可以被測試的中間格式。然后前后端都需要有測試來使用這些契約。一旦契約發生變化，則另一方的測試會失敗，這樣就會驅動雙方協商，并降低集成時的浪費。 　　一個實際的場景是：前端發現已有的某個契約中，缺少了一個address的字段，于是就在契約中添加了該字段。然后在UI上將這個字段正確的展現了（當然還設置了字體，字號，顏色等等）。但是后臺生成該契約的服務并沒有感知到這一變化，當運行生成契約部分測試（后臺）時，測試會失敗了 — 因為它并沒有生成這個字段。于是后端工程師就找前端來商量，了解業務邏輯之后，他會修改代碼，并保證測試通過。這樣，當集成的時候，就不會出現UI上少了一個字段，但是誰也不知道是前端問題，后端問題，還是數據庫問題等。 　　而且實際的項目中，往往都是多個頁面，多個API，多個版本，多個團隊同時進行開發，這樣的契約會降低非常多的調試時間，使得集成相對平滑。 　 首先，我們先假設我們已經有了一份契約，可能是基于JSON格式的，有可能是基于XML格式的，這都不重要。然后，前端會根據這份契約建立一個Mock server，所有的測試都發往這個Mock server。有兩方面的原因：一是這個時候可能后臺的API還沒有開發完成；二是有可能因為網絡等其他方面的原因導致直接調用真實的后臺API會很不穩定或者很耗時。到這里，可能有人就要說了，如果后臺的API實現和之前約定的并不一樣，怎么能保證到了集成的時候雙方還能很順利的集成呢？其實這個問題并不難，只需要讓前端的測試定期連接真實的API執行一遍就能盡早的發現差異性。比方說，在我們平常的build pipeline上添加一個job，讓這些測試每天在午夜里連著真實的API執行。如果，第二天發現這些測試有的失敗了，那么就需要和開發后臺API的人員進行一次溝通了，很有可能由于真實的業務邏輯發生了變化，API在實現的時候，已經和之前的契約不一致了，如果是這樣，那么相應的測試和契約定義就需要更新以滿足最新的業務需求。

參考: http://www.cnblogs.com/whitewolf/p/4686154.html