單元測試VS異步代碼隨機測試的隨想
查看英文原文： Thoughts on Unit Testing vs Ad-hoc Testing with Asynchronous Code
眾多“任務+異步/等待”模式有意思的特性之一是用戶能夠比較容易地對任何操作的結果進行裝飾。微軟的 Lucian Wischik 展示了如何采用這種特性的優勢，以使得您的端到端測試結果更加健壯。
使用Mr.Flakey 就跟在 Windows 8 或者 Windows Phone 8 應用的每一個 await 語句后面加上“.Flakey ()”一樣簡單。
Dim r = Await http.GetStringAsync (uri) .Flakey ()
啟用之后，每個異步調用都將會觸發一個對話框，用戶可以選擇點擊“ok”按鈕， 這樣會像正常一樣返回結果，或者點擊“fail”按鈕來模擬一個網絡或者服務器異常。
為什么使用這種隨機測試而不編寫一套全面的單元測試用例呢？Lucian 解釋如下:
單元測試：以我個人的經驗，單元測試在測試分布式算法中并不是非常有效。測試的時候需要花費相當多的努力建立環境（比如，模擬網絡環境），而且這種測試方法注定不夠全面，并且以我個人經驗來看，單元測試實在是不太適合于發現分布式環境下的缺陷。我懷疑這是因為程序員的大腦經常會沿著他們算法中“正確”的路徑進行思考，而不太擅長面對其他各種錯誤路徑。
（想一想：當你查看并發程序代碼的時候，你是不是一個僅僅通過查看代碼就能夠發現競爭條件的人？你團隊中有人能夠做到這個嗎？你曾經寫過一個發現競爭條件的單元測試用例嗎？至少我還沒有過）
隨機測試： 發現缺陷的一個非常棒的方式是交互式的隨機測試。如果通過用戶界面就能非常容易地模擬錯誤，你就幾乎可以將自己的腦袋設置成自動導航模式，隨機地點擊界面上的各個位置，很快就能發現應用程序運行行為不正確的地方。
我被 Leslie Lampor 在 1990 年研究的“時態邏輯檢查器”迷住了-- 這是一種自動探索巨大指數空間可能性的方法（類似于我們在分布式算法中所面對的問題）。他所發現的在可能性空間“自動隨機遍歷”最后在實踐中證明確實能夠發現所有的缺陷，并且遠遠比對每一個可能性進行詳盡測試更加有效。
</blockquote>來自: InfoQ本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！