我想重新將單元測試引入我的團隊，因爲我們目前的覆蓋率非常差。單元測試有效地工作/任何人都試過裝配方法？
我們的系統是相當大的40多個項目/組件。我們目前使用名爲[SystemName]的項目.Test.csproj將所有測試代碼轉儲並組織爲使用文件夾來表示名稱空間。這種方法不具有可擴展性，並且很難找到測試。
我一直在想加入的測試文件夾中的每個項目，這將使單元測試「的開發商面臨」，使他們很容易找到。缺點是生產版本代碼將包含對nunit，nmocks以及測試代碼和測試數據的引用....有沒有人嘗試過這種方法？
如何每個人都與大型項目的單元測試工作？每個「真正的」項目/組裝都有一個測試項目會引入太多的新項目。
在此先感謝
我個人使用項目內方法。 由於單個項目本身就是一個軟件模塊（因此可以運送或用於其他項目），我認爲最好的方法是將測試與單個軟件模塊聯繫起來，因此它會自動遵循測試代碼。
，我認爲這是一個壞主意，你所陳述的理由，最終不得不在生產代碼的測試程序集的引用，以及一個事實，即所有的測試編譯到你的生產代碼，除非你做一些魔術排除它。
你不說爲什麼測試很難找到。如果他們反映他們正在測試的東西的結構，那麼他們不應該比他們正在測試的代碼更難找到。
你應該有它運行所有測試所有的時間，所以即使測試是不是在開發者面對他們無法從這樣的事實，他們容易破碎的構建方式獲得CI服務器。
我們傾向於在他們自己的項目中進行測試，但該項目位於正在測試的程序集的子文件夾中的測試（或Tests.Integration或任何測試）。這樣，當檢出項目的代碼並且沒有測試項目文件夾污染項目級別的目錄結構時，將獲得測試。但是你最終會爲每個裝配至少有1個測試項目。我認爲這是可以的，除非你有很多小的程序集，但是在那種情況下，你是否真的需要在ide中始終擁有代碼，或者你可以簡單地爲你正在處理的程序集本地和其他程序集只是由dll引用？
我在一個大型項目（500萬行代碼，約160,000個單元測試）上工作過，這個項目用於將測試類放在每個文件的底部，放在一個單獨的命名空間中，並用#if DEBUG包裝。
到NUnit的的參考文獻在生產中存在，但不包括在發佈版本的測試代碼，因此它並沒有使生產的DLL任何較大。
的好處是測試代碼是親臨現場的生產代碼，所以這是從來沒有很難找到測試。還清楚哪些測試屬於哪些類，並且不需要嘗試模擬測試文件夾中的名稱空間層次結構，如果名稱空間或類名稱更改，這總是很麻煩。
它對這個項目非常成功，但意見和里程可能會有所不同這些天:)我目前工作的地方有一個非常類似Sam Holder描述的結構。