如何組織單元測試，不要讓重構成為一場噩夢？

Question

我目前組織單元測試的方法歸結為以下幾點：

• 每個項目都有自己的專用項目和單元測試。 對於項目BusinessLayer ，有一個BusinessLayer.UnitTests測試項目。
• 對於我想要測試的每個類，測試項目中有一個單獨的測試類放在完全相同的文件夾結構中，並且與測試中的類完全相同。 對於一類CustomerRepository從命名空間BusinessLayer.Repositories ，有一個測試類CustomerRepositoryTests命名空間中的BusinessLayerUnitTests.Repositories 。

每個測試類中的方法遵循簡單的命名約定MethodName_Condition_ExpectedOutcome 。 因此，類CustomerRepositoryTests包含測試一類CustomerRepository與Get方法定義如下所示：

[TestFixture]
public class CustomerRepositoryTests
{
    [Test]
    public void Get_WhenX_ThenRecordIsReturned()
    {
        // ...
    }

    [Test]
    public void Get_WhenY_ThenExceptionIsThrown()
    {
        // ...
    }
}

這種方法對我很有用，因為它使得對某些代碼的定位測試非常簡單。 在相反的網站上，它使代碼重構變得非常困難，應該是：

• 當我決定將一個項目分成多個較小的項目時，我還需要拆分我的測試項目。
• 當我想要更改類的名稱空間時，我必須記住更改測試類的名稱空間（和文件夾結構）。
• 當我更改方法的名稱時，我必須完成所有測試並在那里更改名稱。 當然，我可以使用搜索和替換，但這不是很可靠。 最后，我仍然需要手動檢查更改。

有沒有組織單元測試仍然讓我找到測試特定的代碼快速的同時更借本身對重構的一些巧妙的方式？

或者，是否有一些，呃，也許是Visual Studio擴展，這將允許我以某種方式說“嘿， 這些測試是針對該方法的，所以當方法的名稱發生變化時，請非常友好並改變測試” ？ 說實話，我正在認真考慮寫自己的東西:)

Answer 1

經過大量的測試后，我逐漸意識到（至少對我而言）擁有所有這些限制從長遠來看會帶來很多問題，而不是好事。 因此，我們已經開始使用代碼，而不是使用“名稱”和約定來確定它。 每個項目和每個類可以包含任意數量的測試項目和測試類。 所有測試代碼都是根據從功能角度測試的內容（或者它實現了哪個要求，或者它復制了哪些錯誤等）來組織的。 然后，為了找到一段代碼的測試，我們這樣做：

[TestFixture]
public class MyFunctionalityTests
{
    public IEnumerable<Type> TestedClasses()
    {
        // We can find the tests for a class, because the test cases references in some special method.
        return new []{typeof(SomeTestedType), typeof(OtherTestedType)};
    }

    [Test]
    public void TestRequirement23423432()
    {
        // ... test code.
        this.TestingMethod(someObject.methodBeingTested); //We do something similar for methods if we want to track which methods are being tested (we usually don't)
        // ... 
    }
}

我們可以使用諸如resharper“usages”之類的工具來查找測試用例等等......當這還不夠時，我們通過加載所有測試類並運行類似allTestClasses.where(testClass => testClass.TestedClasses().FindSomeTestClasses());反射和LINQ做一些魔術。 allTestClasses.where(testClass => testClass.TestedClasses().FindSomeTestClasses()); 您還可以使用TearDown收集有關每個方法/類測試哪些方法的信息並執行相同操作。

Answer 2

移動代碼時保持類和測試位置同步的一種方法：

• 將代碼移動到唯一命名的臨時命名空間
• 在測試中搜索對該命名空間的引用，以標識需要移動的測試
• 將測試移動到適當的新位置
• 一旦從測試中對臨時命名空間的所有引用都在正確的位置，然后將原始代碼移動到其預期目標

端到端或行為測試的一個優點是測試按需求分組，而不是代碼，因此您可以避免將測試位置與相應代碼保持同步的問題。

Answer 3

關於將代碼與測試相關聯的VS擴展，請查看Visual Studio的測試影響。 它在分析器下運行測試並創建一個緊湊的數據庫，將IL序列點映射到單元測試。 換句話說，當您更改代碼時，Visual Studio知道需要運行哪些測試。

Answer 4

每個項目的一個單元測試項目是要走的路。 我們嘗試過一個大型單元測試項目，但這增加了編譯時間。

為了幫助您重構使用像resharper或code rush這樣的產品。

Answer 5

是否有一些組織單元測試的聰明方法仍然可以讓我快速找到特定代碼的測試

Resharper有一些很好的快捷方式，可以讓你搜索文件或代碼

正如您所說的CustomerRepository類，它們是一個測試CustomerRepositoryTests

R＃快捷方式顯示你在你發現的內容的輸入框中你可以輸入CRT，它會顯示所有以name開頭的文件首先作為Capital C然后是R然后是T

它還允許您通過諸如CR *之類的通配符進行搜索，它將顯示文件CustomerRepository和CustomerRepositoryTests的列表