2012-12-03 132 views
0

我在第一次看單元測試。 因爲我在Visual Studio 2008中,我開始使用測試框架構建。我應該爲以下哪種方法編寫單元測試?

我已經打開按鈕,開始看着填充空白,這似乎一切簡單。

除了我可以看到兩個問題。

1)大量的空白單元測試似乎是多餘的,是否有一個經驗法則來選擇編寫單元測試的方法不是而是。 2)是否有編寫測試讀/寫數據庫的方法的最佳做法(本例中爲SQL Server)

我將給出(1)的示例。

我正在爲WCF Web服務編寫單元測試。我們首先使用wscf.blue編寫我們的Web服務WSDL/XSD。

下面是消耗用戶列表並將它們寫入數據庫的用戶表的方法的代碼(經過嚴格簡化)。

Entry Point 
    | 
    | 
    V 
void PutOperators(PutOperatorsRequest request) (This method is auto generated code) 
    | 
    | 
    V 
void PutOperatorsImplementation(PutOperatorsRequest input) (Creates a data context and a transaction, top level exception handling) 
    | 
    | 
    V 
void PutEntities<T>(IEnumerable<T> input) (Generic method for putting a set of entities into the database, just a for loop, T is Operator in this case) 
    | 
    | 
    V 
U PutEntity<T, U>(T entity) (Generic Method for converting the input to what the database expects and adding it to the DataContext ready for submission, T is Operator, U is the data layer entity, called User) 
    | 
    | 
    V 
(This method calls 3 methods, first 2 of which are methods belonging to "entity" passed into this method, the 3rd is an abstract method that, when overridden, knows how to consume a BL entity and flatten it to a database row) 
void EnsureIDPresent() (Ensures that incoming entity has a unique ID, or creates one) 
void ValidateForInsert(AllOperators) (Does this ID already exists, etc) 
User ToDataEntity(Operator entity) (simple field mapping excersice, User.Name = Operator.Name, etc) 

所以,據我可以告訴我有3個方法是做顯然是可測試的東西:

EnsureIDPresent() - 此方法需要輸入和修改它以易於測試方式 ValidateForInsert() - 此方法需要如果不符合條件,則輸入並拋出異常 ToDataEntity() - 此方法接受輸入,創建數據行實體並填充值。應該很容易測試。

還有:

PutOperatorsImplementation() - 這是在這裏,DataContext.SubmitChanges()和TransactionScope.Complete()被調用。我應該編寫測試來測試寫入數據庫的內容嗎?然後什麼?刪除它們的記錄?不知道在這裏做什麼。

我覺得我應該刪除試驗:

PutOperators() - 自動生成的代碼,一行調用PutOperatorsImplementation() PutEntities() - 只是一個for循環調用PutEntity(),這是一個基礎上的通用方法類 PutEntity() - 調用三個已經具有單元測試和調用DataContext.InsertOnSubmit的方法。

我有一個類似的路徑獲取數據,以及:

GetOperatorsResponse GetOperators(GetOperatorsRequest request) - 自動生成

GetOperatorsResponse GetOperatorsImplementation(GetOperatorsRequest input) - 設置的DataContext

List<Operator> GetEntities() - LINQ查詢

Operator ToOperator(User) - 展平一個數據實體融入其等價的BL實體中。

我想我應該是測試ToOperator()GetEntities()

我應該有它已知良好的測試數據的專用測試數據庫?

這是正確的方法來解決這個問題嗎?

回答

0

對於你應該做什麼和不應該做什麼測試,沒有「硬性和快速」的規則。

單元測試在那裏測試你的書寫作品的任何實現,並使你在重新分解時確信你沒有破壞任何東西。你需要考慮你寫的測試是否會給你帶來價值。

你需要考慮決定什麼樣的代碼覆蓋時,主要的事情是

  • 怎麼可能是我對寫代碼/採寫可能 變化和需要重構?
  • 代碼是否主要寫自定義代碼或autogenrated - 如果 autogenrated再有就是在編寫測​​試你的 小值只是簡單地測試使用的是它的工作 正確(你應該能夠相信它)自動發生器。

您不應該使用數據庫或任何可以在測試環境之外更改的數據來測試數據訪問代碼。相反,可以考慮編寫「Mocks」來模擬數據層對測試的響應。這將確保您的測試一致。考慮看一些模擬框架,如Rhino Mocks或MOQ。

永遠記住你正在寫測試的原因,而不是寫作測試的緣故。如果你不會從你編寫的測試中獲得任何價值(例如,如果你的代碼庫不會改變),那麼就不要寫它們。

+0

好的,有道理,謝謝。我已經開始閱讀犀牛手冊,我想我看到了一個關於我們如何做事的直接問題。我們有很多對靜態屬性的調用,它們在範圍DataContext中查找當前值。我猜這個模擬方法只適用於傳遞信息庫的情況嗎?我們只是把它們拔出來...... – RoboJ1M

+0

如果你正在從物理傳感器或硬件讀取數據,Mock也會很有用,這樣你就不必在一個單元中確保硬件處於特定狀態測試。 – Xantham

+0

聲音對於手持設備測試非常有用,然後在我們使用GPS,GPRS等的地方 – RoboJ1M

相關問題