<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
1、單元測試代碼，直接寫在需要被測試的類中。這種方法的優點很明顯：由於測試代碼同被測試的方法放在一個類中，所以private等方法很容易被測試。但同時缺點也很明顯，該類會被寫得很複雜，估 計很少會有人喜歡看這種代碼，而且萬一客戶不需要這些代碼的話，在最後部署的時候，關del測試代碼，估計也是個大問題。
2、每寫一個需要被測試的類，就寫當前工程下新建一個相應的測試類，名字可以在被測試類後面加上Test以示區別。
這種方法的優點是結構比較清晰，在比較小的工程中使用還算不錯，修改測試代碼也比較方法。缺點同樣是部署時刪除單元測試代碼比較麻煩，同時solution太大，有很多project時，有很大侷限性。
3、solution有很多個工程時，專門新增加一些工程，用於寫單元測試，比如有一個ClassLibrary3工程，則建一個TestForClassLibrary3工程，單元測試類放到這個工程中去。
由於是以工程爲單位，所以部署起來很容易，只要把這幾個工程去掉就可以了，將來再要用，也只要加上就可以了。不過操作相對來說比較繁瑣，沒有前2種方法便捷。
4、以上3種方法都需要在項目的solution中增加東西，但如果你的項目不允許你增加任何測試類或工程（雖然感覺很愚蠢，但的確很多公司不允許程序 員這麼做），或者你根本沒有權限增加工程或文件，這3種方法將都不能使用，這時可以用第4種方法。比如你想測試ClassLibrary3工程下的 Class1類，你可以先build你的項目，生成ClassLibrary3工程的dll文件，然後在你本地建一個測試工程，引用這個dll，就可以不 需要修改你的項目了。
這種方法的最大優點是不需要修改你的項目，不過缺點也很多，不夠靈活，操作複雜等。
我個人比較多用2，3，在很小的模塊中有時會用1，不過比起用1來，可能使用TestDriven.NET更加方便些。