這一篇其實並不會像前兩篇講太多有關工具設定或調整的內容，著重在一個重點「快」。很多人都會問我「要怎樣才能快速產出？」「要如何才能有效率的開發？」，要不然就是跟我直接說要我教他們如何快速寫程式。
其實這有很大的誤會，因為熟悉我的人都會知道我其實寫程式是很慢的，慢就算了，而且會非常吹毛求疵，因為我不希望我所寫的程式在交付上線之後會有嚴重的問題出現，所以我會很嚴謹地寫程式，尤其現在我已經在專案開發導入測試之後，我一定會在交付前將所有功能的測試給完成並通過後才會交出去，所以我寫程式會快嗎？當然不會有多快，但是我還是可以在同樣的時間內將功能給完成而且還包含測試，這並沒有什麼魔法或奇蹟，只是開發習慣的養成而已。
West Wind Web Surge (以下簡稱 WebSurge) 不只是用於 ASP.NET Web API 的壓力測試功能，也可以對 ASP.NET MVC, ASP.NET WebForm 或是其他網站應用服務進行簡單的壓力測試，而 Load Testing 也僅是 WebSurge 其中的一個功能，WebSurge 也有類似 Telerik Fiddler 的功能，可以針對指定的瀏覽器所發出的 Request 和接收的 Response 進行擷取，有興趣的朋友可以去 WebSurge 的官方網站裡進行瞭解。
不過這一篇文章只針對 Load Testing 這個功能作簡單的說明。
我在開發專案的時候一定會用到很多的介面，可以從我的一些系列文章裡可以看到，對於系統的抽象化是否能夠瞭解、掌握與充分使用，對於大型、複雜系統的分解與後續的測試都會有相當大的幫助，如果你對於系統抽象化的分析與解構都能夠相當上手，很多看似複雜、難以處理的問題都可以迎刃而解。
話雖這麼說，還是很多人對於物件導向的抽象化還是相當模糊，更別說將抽象化的概念去轉化到實際的專案開發裡頭，所以一個很直接的點就可以看出系統的結構是否良好以及後續的維護，甚至於是否具有可測試性都可以看出，就是看專案裡頭有沒有使用到「介面 Interface」，我知道這一段說法相當武斷與偏頗，不過就我目前所接觸到的情況都能夠看出端倪與跡象。
很多人對於介面，因為不瞭解以及不知道如何應用在實務上，所以就乾脆選擇不用。而另外一種狀況則是當專案使用了介面之後，在進入偵測模式或是在 Design-Time 時，當想要去看某個繼承於介面的方法時，按下 F12 後就會直接移到介面的定義裡，而不是繼承實作類別裡，然後為了要找真正的實作方法就要找很久 …… 不要認為有人因為這個理由就不使用介面，我還真的有碰到一個團隊因為這樣而禁止在專案開發時使用介面，夠瞎吧，我只能說世界之大、無奇不有，其實這肇因於對於 Visual Studio 的不熟悉以及個人觀念的不好而犧牲了讓系統邁向良好架構的機會。
LINQPad 的好用以及它是 .NET 開發人員必備的工具，這些我想就不用一再地強調，如果你還真的不知道為何 LINQPad 是如此必須的話，請參考這部落格裡有關 LINQPad 的文章。
另外不要只是用著免費版的 LINQPad 然後跟我靠北說很難用，已經再三強調免費版給你基本的功能，但是要能夠發揮其最大的效用就必須購買使用付費版。另外也要說，不要想著去找破解版，身為一個資訊開發人員，請先尊重別人的專業與智慧財產，使用者付費的觀念要落實，學會尊重別人的專業，才能讓別人也尊重你的專業。
再過不久 LINQPad 5.0 將會推出正式版，其實目前 5.0 Beta 也已經發佈一段時間了，所以想要嘗鮮的朋友可以前往 LINQPad 的官網下載，雖然 LINQPad 5.0 的新功能裡有幾項是比較引人注意的，就來看看有哪些新改變。
在上一篇「測試專案使用 LocalDB - 使用 Entity Framework 的情境」說明了測試專案裡如何有 LocalDB 的類別庫專案加入參考引用，然後在做一些設定處理後就可以讓測試專案使用 LocalDB 去對有使用 EF 的程式作單元測試。
但如果跟我一樣在開發時有使用 NCrunch 的朋友，可能就會遇到跟我同樣的問題，那就是在 Visual Studio 裡的測試總管執行測試都是正常的，但是使用 NCrunch 狀況下就是給你亮紅燈，測試程式並沒有任何問題，這是 NCrunch 的設計上以及預設設定所造成的執行錯誤結果。
如果沒有特別去做處理的話，很多人因為不得要領就可能會選擇讓 NCrunch 忽略有使用到 LocalDB 的測試，這還蠻可惜的，因為 NCrunch 的確是個相當好用的工具，所以就必須要想辦法讓一般使用的測試總管的執行可以正常之外，也必須要讓屬於設計期間的測試輔助工具 NCrunch 一樣可以正常的執行。
