進入新公司之後，開發方式跟以前相比變化很大。以前公司做的專案基本上沒有什麼文件，只有一系列的使用者需求，然後根據需求來決定該怎麼做，做成怎麼樣。但
在這裡，動手之前首先需要準備user story，即虛擬出終端使用者的操作，寫成文件來決定我們應該如何做，怎麼去做。
最初，我是根據user story的定義來定義好介面，然後根據介面編寫unit test，最後去實現然後測試。當user
story並不是很複雜的時候，這種方法的確不錯。然而，當你所要做的某些方法很複雜，需要考慮很多情況的時候，你會發現你的測試和實現可能會將你的**
弄的一團糟，因為你要注意的地方太多了！
那麼，這個時候，為什麼不讓我們的測試跟著我們定的user story來走呢？
舉個例子：有乙個系統需要經常性的和伺服器同步，那麼對於第一次同步和以後同步肯定會有所差別。正常情況下我們很難去寫乙個測試直接去測試你的方法的所有
方面。但是如果根據user
story來編寫測試呢？比如這裡我們編寫firstsynchtest來測試第一次同步該做什麼，secondsynchtest來測試第二次同步該做
什麼。這樣，對於每次，我們只需要集中精力解決第一次我們要實現方法的某些功能，然後在第二次需要的時候再去考慮其他情況，但同時只要去保證第一次的測試
通過便可以了。
這樣來做還有乙個好處就是user story和unit test是乙個相互迭代的過程，在我們編寫unit test的時候，也同時是對user
story的一種檢查，因為unit test的編寫直接去參考所編寫的user
story。通常情況下對於我們開發人員只能給出乙個我們認為使用者該怎麼做的步驟，並且很多時候，我們會遺漏一些簡單的步驟。但在編寫unit
test的時候發現user story是跳躍式的，於是回頭新增user story，然後繼續更新unit test。
上面的方式最典型的乙個例子就是在產品的公升級中：最初做好的產品可能使用者希望我們新增一些新的特性進去，但是這些特性會分散到使用者操作的各個環節中。如果
按照user story來編寫的unit test，那麼我們只需要回到特定的地方，加入新特性的test，然後實現並測試，這樣是不是覺得很直觀呢？
總的來說這篇東西寫的很枯燥，因為要將自己的一些體會寫出來真的是很難。因為很多時候都是噢的一聲，自己恍然大悟了，但是讓你說出來卻未必說的清楚。如果你覺得我的這種想法很危險，歡迎給我提出來
我的單元測試認識之路 上
本文並不是告訴你如何使用nunit進行單元測試，關於你如何進行單元測試的文章已經有很多。我這裡只是說說我接觸單元測試這一年半的時間自己所領悟到的一些東西，當然這只是我個人的心得，估計裡面也會有錯誤，期待各位高手來對不對的地方進行指正。初次接觸單元測試是一年半以前參加乙個工作流引擎的開發。那時我剛畢業...
visual studio 單元測試的認識
單元測試 unit testing 對軟體中的最小單元進行檢查和驗證，其一般驗證物件是乙個函式或者乙個類。team test 是 visual studio 整合的單元測試框架，它支援 microsoft.visualstudio.testtools.unittesting dll 通過上面的方法，...
單元測試之路（二）
引入測試集，testsuite，用於存放測試用例的容器 testsuite方法 init self,tests 初始化，直接新增測試用例 addtest self,test 新增乙個測試用例 addtest self,tests 新增多個測試用例 texttestrunner執行測試集 countt...