2009-10-08 99 views
3

我有一個類(很多)有屬性。有些人有邏輯,有些則沒有。假設我想測試這些屬性,我該怎麼做呢?如何(策略)以BDD風格對單元測試屬性(get/set)進行測試?

最近,我對創建單元測試的BDD風格感興趣。

參見herehere

所以我會做一個上下文的設置 - 基本上創建SUT並加載任何需要的東西。 然後在每個Observation(測試方法)中,我會驗證某個特定屬性是否包含它應包含的內容。

這是我的問題。如果SUT有20個屬性,那麼我是否創建了20個觀測/測試?可能更多,如果其中一個屬性包含更多有趣的邏輯我猜。

[Observation] 
public void should_load_FirstName() 
{ 
    Assert.Equals<string>("John", SUT.FirstName); 
} 

[Observation] 
public void should_load_LastName() 
{ 
    Assert.Equals<string>("Doe", SUT.LastName); 
} 

[Observation] 
public void should_load_FullName() 
{ 
    Assert.Equals<string>("John Doe", SUT.FullName); 
} 

但是,如果在單一觀察中彙總簡單的那個,會更好嗎?

[Observation] 
public void should_load_properties() 
{ 
    Assert.Equals<string>("John", SUT.FirstName); 
    Assert.Equals<string>("Doe", SUT.LastName); 
    Assert.Equals<string>("John Doe", SUT.FullName); 
} 

或者如果我使用自定義屬性(可以多次應用於方法)會怎麼樣。所以,我可以做的可能,像:

[Observation(PropertyName="FirstName", PropertyValue="John")] 
[Observation(PropertyName="LastName", PropertyValue="Doe")] 
[Observation(PropertyName="FullName", PropertyValue="John Doe")] 
public void should_load_properties() 
{ 
} 

回答

4

一般來說,你應該爲每個測試只有一個邏輯肯定之後努力。優秀的書xUnit Test Patterns包含了一個很好的討論,但重要的是,如果只有一個測試失敗的原因,它可以更容易地理解違規發生的位置。這可能迴歸測試比BDD,但更多的相關...

所有這一切都意味着你編寫一個測試驗證所有屬性的選項可能是最有吸引力的,儘管你可以認爲所有驗證屬性是一個邏輯斷言...

xDD(TDD,BDD,無論)的更中心原則是測試應該充當可執行規範。換句話說,當你看看測試不僅什麼正在測試,而且爲什麼的預期值是這樣,它應該立即顯而易見。在你的例子中,不太清楚爲什麼SUT.FirstName預計會是「John」而不是「Jane」。

如果可能的話,我會寫這些測試以使用Derived Values而不是硬編碼的值。

對於可寫屬性,我經常編寫簡單的驗證getter函數返回分配給setter的值的測試。

前面的只讀屬性,我經常寫測試,驗證值匹配構造函數參數。

這樣的測試可以封裝成封裝常用測試用語的可重用測試代碼。我目前正在致力於library that can do just that

+0

感謝馬克的建議。回來的時候,你的CallContext博客文章幫了我很多! 我跟隨了Meszaros網站上Derived Values的鏈接並閱讀了它(在你的網站之後)。我不確定我會像實施逆向示例一樣去實現它的極限。我認爲在輸入旁邊有一個變量expectedResult,然後使用文字值。 在我上面的例子中,我聽到你 - 這並不明顯,但我從本地磁盤加載測試數據來創建SUT(這是一個驗收/交互測試)。我需要找到更好的方法來指定輸入值... – 2009-10-09 13:30:50

0

查看其他SubSpec語法([Specification]示例) - 在這種情況下,末尾的每個Assert代表測試的單獨執行。我原來打折的lambda濫用的語法,但現在我一直在使用它。