2009-07-01 107 views
3

想象我有一個方法:如何區分單元測試方法?

void Method(bool parameter){ 
    if(parameter){ 
     // first case 
    } else { 
     // second case 
    } 
} 

你首選的單元測試組織方法?

選項1:

void MethodTest(){ 
    // test first case 
    // test second case 
} 

選項2:

void MethodTestFirstCase(){ 
    // test first case 
} 

void MethodTestSecondCase(){ 
    // test second case 
} 

回答

6

在這種情況下,我會分別測試兩個。

話雖如此,我並不是教條主義的「每測試只測試一件事」的方法。有時候,在同一個測試中測試多個事物會更具實際意義 - 特別是如果達到一個終點意味着要經過另一個點,那麼將兩者結合起來有時可以。

在這種情況下,你真的會測試兩個單獨的事情,而不是一個到另一個的路上,所以我會分裂他們。

+3

+1爲「一個在另一個的路上」。這通常是在單個測試中進行多重檢查的理由。 – 2009-07-01 20:11:01

4

選項2

你應該在每次試驗測試的只有一件事。如果測試不止一件事情,那麼給測試一個好名字也很困難。

當測試失敗時,應該很容易找到錯誤,而不使用調試器。如果測試涵蓋多個事件,那麼錯誤可能是多個地方。

3

選項2通常是優選的。

在單元測試運行器中,您可以分別獲得每個測試的可見性,而不必在發生錯誤時查看發生故障的位置。

此外,隨着您的發展,更容易運行更專注的測試以更快地獲得反饋。

0

我會有一個測試類(套件),測試所測試的類中的所有不同方法。此類(套件)對於特定功能的每個變體都會有不同的測試方法。這並不意味着您必須在方法的每行代碼中進行一次測試。您可以根據單一方法決定「特徵」的粒度,但通常很小。在你的情況下,我會說你有兩個「功能」,一個是參數通過測試時,另一個是失敗。因此,對於這種方法,我至少要進行兩次測試。通常,每個測試用例只有一個或者幾個斷言。

2

對於選項1,如果第一種情況失敗,則根本不會測試第二種情況。對於選項2(在大多數單元測試框架中),如果第一種情況失敗,則第二種情況仍將被測試。

這使得選項2更勝一籌,因爲您可以區分只有第一種情況被打破的情況和兩種情況都被打破的情況,這使得在事情出錯時更易於調試。

1

我傾向於使用方案3:

[TestClass] 
public class When_parameter_is_a { 
    setup() {} // arrange 
    execute() {} // act 
    [TestMethod] 
    this_should_happen() {} // assert 
    [TestMethod] 
    this_should_happen_too() {} //assert 
} 

[TestClass] 
public class When_parameter_is_b { 
    setup() {} 
    execute() {} 
    [TestMethod] 
    this_should_happen() {} 
    [TestMethod] 
    this_should_happen_too() {} 
} 

然後測試所有的預期行爲的每一個部分。這是一種BDD風格(行爲驅動設計)測試,強調在某些情況下的行爲,而不是測試方法的「實施」。

+0

+1用於BDD和MSTest – 2009-07-01 20:27:41

1

也沒有。

不要考慮測試類的方法,而是考慮測試類的作用 - 它提供給其他對象的服務。當你這樣做時,你會發現你沒有以被測試的類的方法命名的測試方法。而且,當多個測試執行與被測試的類相同的方法時,您不會遇到爲測試找到名稱的問題。