我們搞開發的往往覺得自己寫的**沒問題，用不著測試，以前，我也這麼認為，覺得測試浪費時間，也就沒仔細研究過測試。
最近，閒來想試試單元測試，結合之前的程式設計經驗，發現，單元測試至少是保證軟體質量的最佳方式之一。一波一波程式設計師開發、維護乙個產品，程式設計師之間的差別太大了，就像「明顯沒有錯誤」和「沒有明顯錯誤」的區別，怎麼來保證產品在不斷迭代中的質量，保留裡面正確的部分，去掉bug呢？架構設計裡面講究面向介面，單元測試就能起到介面的作用。
通過單元測試的類，它的行為是符合當初單元設計的目標的。只要編寫單元測試時，從多方面檢驗類的行為，就能確保在這樣的情景下，類是符合設計的。在vistual studio中，最簡單的單元測試就是使用本身自帶的功能（不需要從網上找nunit的程式集，直接在專案上引用"microsoft.visualstudio.qualitytools.unittestframework"程式集就ok了）。還有另外乙個好處，是方便除錯。單元測試專案可以在測試執行時，對被測試類下斷點，非常節約除錯時間。
我是這麼做的，單元測試的**放到獨立的專案中去，引用要測試的專案，在被測試專案中新增assembly特性如下：
[assembly: internalsvisibleto("
projky.unittests
")]
這樣，單元測試就能對被測試專案中internal修飾符的類可見，又不破壞程式集的可見性。
舉乙個簡單的需求，要將如「30d9132169211a45」或者「30-d9-13-21-69-21-1a-45」或者「30 d9 13 21 69 21 1a 45」這樣的16進製制字串轉換為byte陣列。設計了乙個bytestring的類來實現需求。
internalclass
bytestring
else
if (value.indexof("
") > -1
) debug.assert(value.length % 2 == 0, "
invalid byte string length.");
list
list = new list(value.length / 2
);
for (int i = 0; i < value.length; i += 2
)
return
list.toarray();
}static
int getinteger(char
ch)
int value = 10
;
switch
(ch)
return
value;
}}
那麼，簡單驗證該類的行為（介面）可以編寫下面的測試類：
[testclass]public
class
bytestringtest
}
如果單元測試執行失敗，例如assert.istrue()方法中，引數為false，則在vs中會拋異常，這樣，就知道**不正確了。
注意用[testclass]標記作為單元測試承載的類，是public可見性，而裡面單個的獨立測試方法，則採用[testmethod]標記，同樣是public可見性。
在visual studio裡面還有乙個技巧，按ctrl + r，a可以自動執行單元測試專案。如果被測試類有斷點的話，測試到該位置時，也會斷下來。
初次使用Nunit進行單元測試
初次使用nunit進行單元測試 本示例出自以下鏈結 每個.net 關於tdd idior 的以下鏈結 關於nunit 的詳細使用方法參照以下鏈結 在.net環境中實現每日構建 nant篇 我用的以下 測試的，測試通過，很簡單，但是是好的開始，呵呵。using system using system....
單元測試總結反思 單元測試後反思
周四晚上考試第三單元，今天上午補課，講評完試卷，因為試卷選擇題多，批改較快，考試成績令人非常不滿意。講評試卷效果也太理想。於是反思如何更好的應對各類語文試題？學生平時課本知識的積累不少，為什麼一到做題就錯誤百出？如何更有效的講評試題？因題施教，因人而評。由點及面，化評為練。澄清方向，錘煉思維。對於閱...
Google Test單元測試使用
google開源了很多實用的模組，比如google gtest google gmock google glog google gflags google ctemplate google sparsehash protobuf perftools，gtest是c 的測試模組，提供豐富的測試方法 軟...