共用方式為


本文章是由機器翻譯。

編輯的話

加入非同步測試

Michael Desmond

Michael DesmondMSDN 雜誌在這一問題的鉛條專注于一個共同的主題:管理單元測試非同步代碼專案的任務。

Stephen Cleary撰寫了大量關於非同步開發在過去幾年在這裡在 MSDN 雜誌和他篇"單元測試非同步代碼"的專題文章探討了如何單元測試必須加以修改以證明 async 專案。他看著一些當前的單元測試框架 — — MSTest、 NUnit 和 xUnit 等 — — 並提供戰略,以確保獲得最佳結果。斯文大採取後續行動的第二次的專題文章內這一問題,"單元測試非同步代碼:三個解決方案更好的試驗"。他提供了改進的設計,測試的非同步代碼與消除是緩慢和脆弱的單元測試的目標的三種解法。

當然,非同步程式設計是在 MSDN 雜誌在這裡持續關注的話題。回來在 2011 年 10 月的問題,Microsoft 專家EricLippert、 麥斯 Torgersen 和StephenToub 寫了三級跳預覽新的非同步非同步主題特徵和等待Visual Studio2012 中的關鍵字 (msdn.microsoft.com/magazine/hh463583)。自那時以來,我們已經發佈了十幾個專題文章側重于非同步開發。其中之一 — — 佳利律師事務所的 2013 年 3 月第條,"最佳做法在非同步程式設計"— — 在過去的兩年中是最多人閱讀的文章 (msdn.microsoft.com/magazine/jj991977)。

重點是,非同步是熱門的話題 — — 和很好的理由。作為大這個月,在他的文章中寫道"是否對於基於 CPU 的並行或 IO 基於併發,開發商正在採用非同步來説明提供最重要的資源,並最終做更多與少。回應更快的用戶端應用程式和可擴充性更強的伺服器應用程式都是觸手可及。"

非同步發展的好處是很明顯 — — 尤其是在越來越以雲計算為導向的世界 — — 但非同步程式設計對於開發人員來說,是新的實踐的挑戰。如克利裡在一次採訪中說:"很多非同步教程說明如何使用非同步/等待,但他們不准備非同步病毒式特性的開發人員。所以當他們開始寫單個非同步方法,這種等待非同步/東西保持增長通過他們的代碼,這些警告去和他們找資料來核實,這是不正確的。"

這就是為什麼這個月的 MSDN 雜誌的問題導致了與兩篇文章側重于單元測試非同步代碼。測試是那些可以得到推到一邊當時程表得到嚴格的事情之一。然而,一個嚴謹、 紀律嚴明的測試製度是實現一致的代碼品質的關鍵。這兩個特點本月説明開發人員確保其非同步發展發生在有條不紊的和受支援的環境中。

"大多數單元測試非同步代碼所面臨的挑戰是單元測試同步代碼相同。代碼是容易測試,當它設計好的"克利裡說。"對於非同步代碼,功能更強大的方法可以説明 — — 換句話說,返回結果而不是設置值作為副作用。"

大說對重點測試工作,重要的是可以最終由測試從自訂代碼正在調用的庫代碼的開發人員。"你不需要寫一個測試,確保 Microsoft Task.Run 真的作品。相信我,它的工作原理。您的測試會更簡單和更清潔的如果你設法測試只是您自己的代碼,"大說。

是你 dev 店編寫非同步代碼和你如何有適合您的測試,來容納它嗎?發郵件給我在 mmeditor@microsoft.com


Michael Desmond 是 MSDN 雜誌總編輯。