有時候，在測試過程中，可能會用到測試樁。舉個例子，模組a是我們的被測試系統，但是模組a需要從模組b獲取到需要的資料才能正常執行，但是模組b還沒有ready，那這種情況下如何測試模組a呢？這個時候就需要乙個測試樁，用測試樁來模擬模組b響應模組a的請求。
尤其是一些新手，一聽到測試樁，可能就懵逼了，覺得是乙個超級高大上的東西。其實它的原理非常簡單，幾行**就能搞定的事情。通常情況下，測試樁就是乙個執行著的普通http/https服務，本身沒有業務邏輯，僅僅被動響應被測試系統的請求，返回預定義的結構化的測試資料。這裡聽上去比較拗口，但是感覺也不太好用人話表述，直接上圖吧。
這裡一定要弄清楚誰是被測試系統，誰是測試樁，之前在評審乙個測試的時候，發現乙個員工稀里糊塗廢了半天勁，把被測試系統給模擬掉了，自動化用例直接呼叫測試樁，我當時想死的心都有了。
既然原理這麼簡單，那實現起來肯定也不會複雜。起乙個http服務，跟前請求的路徑和方法，響應對應的結構化資料就可以了。
我們舉個例子。
當收到http get請求，並且路徑名稱是「/getinfo」的時候，返回狀態碼200，外加響應資料；
當收到http get請求，並且路徑名稱不是「/getinfo」的時候，返回404；
當收到http post請求，並且路徑名稱是「/profile」的時候，返回狀態碼200，外加響應資料；
當收到http post請求，並且路徑名稱不是「/profile」的時候，返回404。
這個例子的邏輯夠清晰吧？ 廢話不多說，直接上源**（這裡的**是當年用python2寫的，如果現在用flask實現，會更加精煉）。
:# 定義函式，用於處理http get請求
defdo_get
(self)
:# 當請求path為/getinfo的時候，響應200
if self.path.find(
"/getinfo"
)>=0:
result_code =
200 content =
# 否則，響應404
else
: result_code =
404 content =
'}' self.send_response(result_code)
self.send_header(
"content-type"
,"text/plain; charset=utf-8"
) self.send_header(
"content-length"
,str
(len
(content)))
self.end_headers(
) self.wfile.write(content)
# 定義函式，用於處理http post請求
defdo_post
(self)
:# 當請求path為/profile的時候，響應200
if self.path.find(
"/profile"
)>=0:
result_code =
200 content =
# 否則，響應404
else
: result_code =
404 content =
'}',
self.send_response(result_code)
self.send_header(
"content-type"
,"text/plain; charset=utf-8"
) self.send_header(
"content-length"
,str
(len
(content)))
self.end_headers(
) self.wfile.write(content)
# 定義http server的埠和ip位址，指定ssl證書，啟動http server
)為了展示執行效果，這裡簡單寫了幾個自動化測試用例來直接請求測試樁（重要的話說三遍，真實情況下，測試用例不可能直接呼叫測試樁，測試用例請求的一定是被測試系統）。
如下**，在txt檔案中簡單定義了4個測試用例，對應上述的4種情況。
$ python2 debug_stub.py這個時候，測試樁終端會列印出對應的請求。
很簡單吧。
手把手教你寫Undo Redo程式
手把手教你寫 undo redo程式 undo redo 操作是很多具體編輯功能的軟體所不能缺少的。最典型兩種型別就是文字編輯和影象編輯軟體。然而它的實現在某種程度上來說也不是很簡單。我也廢話少說。要在程式中支援 undo redo 操作，就需要儲存一些必要的資訊，這個是眾所周知的。如果想支援無限級...
手把手教你寫Undo Redo程式
手把手教你寫undo redo程式 undo redo操作是很多具體編輯功能的軟體所不能缺少的。最典型兩種型別就是文字編輯和影象編輯軟體。然而它的實現在某種程度上來說也不是很簡單。我也廢話少說。要在程式中支援undo redo操作，就需要儲存一些必要的資訊，這個是眾所周知的。如果想支援無限級的und...
手把手教你寫ORM（三）
昨天處於暈死狀態，少寫了乙個元件，還需要乙個元件用來專門管理cache的，這裡說道為什麼要分這麼多元件，其實這是習慣問題，很多人喜歡寫乙個很大的dll，不過我比較喜歡拆分，小粒度的專案比較好管理和單獨測試，把用單元測試驗證好了的小組件湊起來除錯和寫成乙個巨大的dll慢慢一行行的追蹤 肯定是前者更加舒...