2010-09-01 80 views
1

我感興趣的是寫一個類,它的公共API單元測試的最好途徑,就是某種流動的,例如:測試用流動的類

public class PaginatedWriter { 
public void AppendLine(string line) { ... } 
public IEnumerable<string> GetPages() { ... } 
public int LinesPerPage { get; private set; } 
} 

該類對文本進行分頁線到給定每頁的行數。爲了測試這個類,我們可能會碰到這樣的:

public void AppendLine_EmptyLine_AddsEmptyLine() { ... } 
public void AppendLine_NonemptyLine_AddsLine() { ... } 
public void GetPages_ReturnsPages() { 
writer.AppendLine("abc"); 
writer.AppendLine("def"); 
var output = writer.GetPages(); 
... 
} 

現在,我的問題是:它確定以使最後的測試方法AppendLine()的調用,即使我們正在測試的GETPAGES( ) 方法?

我知道在這種情況下一個解決方案是使AppendLine()虛擬並覆蓋它,但問題是AppendLine()操縱內部狀態,我認爲這不應該是單元測試的業務。

回答

0

我看到的方式是,測試通常遵循像「設置 - 操作 - 檢查 - 拆解」的模式。

我把大部分常用設置和拆卸集中在各自的功能中。

但是對於測試特定的設置和拆卸它是測試方法的一部分。

我沒有看到使用該對象的方法調用來準備被測對象的狀態。在面向對象程序設計中,我不會試圖將操作狀態與操作分離開來,因爲範例花費了很大的努力來統一它們,並且如果可能的話甚至隱藏了狀態。在我看來,被測單元是類 - 狀態和方法。

我在代碼中通過將操作塊和驗證塊的設置塊與空行分開來進行視覺區分。

+0

是的,看來如果我們嚴格應用「僅測試一種方法」規則,我們最終會得到一堆具有過程接口的類。 – Mohammad 2010-09-01 18:41:12

0

是的,我會說這絕對沒問題。

以任何方式測試實用。我發現測試正好在每種測試方法中都存在太多的教條。這是一個可愛的理想,但有時它只是稍微不那麼純粹的替代品。