網站後端一般從下往上有Entity層（對應DB table） —> Dao層（對應DB table增刪改查各種操作）—> Service層(業務邏輯層，調用dao層和DB打交道) —> Controller層（對應http api urls，調用service）。
前後端分離開發的話，後端必須做到充分的自測，才能保證前後端聯調時不出大問題。如果Dao層使用JPA的話，其實不需要測試，除非用錯了。那麼，針對entity層和service/controller層，後端開發時怎麼自測一直是個問題縈繞在我心頭。
現在這個問題的兩個部分全部找到了答案，有種打通了任督二脈的快感，實際上是察覺到，方法論和工具層面，不管是開發還是測試，是相通的。以往自己的技能圖是這一塊，那一塊，現如今塊與塊之間融會貫通起來了，點滴積攢外加思索，終歸會形成全局觀。entity層的測試方案請見上篇博文：構建HibernateUtil測試Entity層代碼 本篇會就service/controller層測試給出我認爲適合我們項目的解決方案。
首先，我研究了一天半SpringBoot框架裏面自帶的Test模塊。確實，使用MockMvc再配合各種註解可以在unit test裏去啓動SpringBoot App(或者某個要測試的controller類)，然後發送request（可以帶參）驗證response。然而我們的後臺有加session攔截器，不帶着合法sessionId過來的request會被deny。接着我又去研究怎麼樣先登錄，拿到服務器種的SessionID，然後怎麼樣帶着這個sessionId繼續後續的api測試。沒有成功…不知道是框架不支持，還是我不會用。
其次，我的api沒有網上demo裏的那麼簡單，請求/hello然後驗證響應裏面包含"Hello World"。我的API裏要增刪改查的，都是要跟數據庫打交道的，成功的話也都會反映在數據庫表裏的。google了很久，發現，就算用mockito把controller依賴的service/dao都Mock出來，也根本達不到我的目的它們都是Mock的啊，所以不會真的去DB裏面增刪改查啊！沮喪…
週五開完早早開完週會，準備跑路，突然靈光一閃，可以用抓包工具直接發請求的呀，篡好request header，篡好參數json串，先去請求login api，reponse裏面會有setCookie:JSESSIONID=…什麼的，把這個合法的JSESSIONID拷貝出來，加到下一個請求的Header裏面去就好了。
說幹就幹，先從瀏覽器裏面登錄我們網站，把請求login api的header和參數複製到fiddler，請求成功後，把sessionid加到後面request header裏面去，增刪改查api調用之後，觀察response裏的數據和DB表裏的數據就成了。最後再測試一些邊界輸入及錯誤輸入，服務器端能夠hold住並且response裏有合適的msg，就行了！
有一點比較神奇的是Fiddler裏發GET請求，如果還帶參數的話，參數必須直接接到url後面去，即?param1=1¶m2=2這樣子，不能以json串的形式放在Body裏。
還有個點比較疑惑，fiddler裏面HTTP版本必須選擇1.1，不然服務端不認，返回505（即版本不支持），Why？？難道我們的服務端有限定HTTP版本還是咋地…有待挖掘…
所以，針對我們的網站項目，fiddler或者任何抓包工具就可以完全做到後端controller/service層的自測了。效率很高，簡單。我想，好的解決方案往往都不是複雜的，而是簡單的。
不過實際上，要想在代碼層面實現controller/service層的測試，使用apache的HttpClient再配合unit test就可以了，加上這些unit tests更穩妥些，任何時候想運行就運行。