2011-11-14 218 views
0

我正在使用框架4.0中開發的asp.net web表單項目。目前它沒有任何單元測試。代碼覆蓋率分析

我正在爲希望引入單元和集成測試的站點添加新功能。不熟悉代碼覆蓋的概念我希望爲新功能獲得很高的百分比。

我將使用visual studio和rhino mocks提供的集成測試環境進行模擬生成。對於一項新功能,我希望實現什麼級別的代碼覆蓋率?對於代碼覆蓋的新手來說,如何衡量網站的特定功能呢?

回答

7

它可以持續獲取代碼覆蓋率在單元測試中接近95%,但你需要時刻關注你正在測試的內容,以及你在嘲笑什麼。

通過具有缺陷模擬的單元測試的100%代碼覆蓋比根本沒有測試覆蓋更差。一個糟糕的模擬會導致錯誤的安全感 - 你認爲你知道一些關於你的代碼在真實世界中的表現,而事實上你什麼都不知道。因爲你對這種錯誤的知識有信心,所以你知道的並不多。如果你至少沒有測試,那麼你會擔心你的指導。

嘲笑是一個偉大的測試工具,但你必須記住,你的嘲笑永遠不會超過你對現實世界的看法。您通常不會在現實世界代碼的主流中發現問題。在漩渦中,真實世界偏離理性預期,而嘲笑會導致你陷入虛假的安全感。

集成測試對現實具有更好的把握,因爲您通常對真實系統運行。但在集成測試中模擬失敗案例非常困難,以清除代碼路徑中的所有角落案例,並排除最後5%的代碼覆蓋率。單元測試擅長強制錯誤條件並執行代碼的錯誤處理。

小心不要過多地讀入代碼覆蓋率統計信息。你知道他們說什麼:謊言,該死的謊言和代碼覆蓋率統計。 ;>代碼覆蓋率數據是深入瞭解你的單元測試正在做什麼的有價值的工具,但這不是絕對的事實。代碼覆蓋率結果可以表面浮華,但需要在理解的基礎上鍛鍊。

很少有代碼覆蓋工具會告訴你整個故事的麻煩。最簡單的告訴你,在測試運行期間的某段時間執行的一行代碼。他們不會告訴你該行是否通過一段代碼在所有可能的代碼路徑上執行。部分原因是因爲代碼路徑排列的數量隨着每個附加的if語句呈指數級增長。這種增長的程度很難管理,而且難以形象化。

考慮以下代碼:

public class Class1 
{ 
    public static void foo(bool a, bool b) 
    { 
     int x = 100; 
     if (a) 
      Console.WriteLine("statement a"); 
     else 
      x -= 50; 

     if (b) 
      Console.WriteLine("statement c"); 
     else 
      x -= 50; 

     double y = 10/x; 
    } 
} 

[TestClass] 
public class UnitTest1 
{ 
    [TestMethod] 
    public void TestMethod1() 
    { 
     Class1.foo(true, true); 
     Class1.foo(true, false); 
     Class1.foo(false, true); 
    } 
} 

代碼覆蓋率會告訴你,在這個代碼片段的所有線已通過單元測試行使。

恭喜!您已經實現了榮譽100%代碼覆蓋率徽章。哦,順便說一句,你的代碼仍然包含一個崩潰錯誤。

覆蓋率結果是正確的,因爲單元測試確實執行了片段中的每一行代碼。但這不是完整的故事,完整的真相。 (a,b)=(false,false)通過同一個執行上下文中的其他子句的代碼路徑不會被單元測試執行。這就是在真實世界中運行時會導致零誤差的一條路徑。

不要誤解我的意思 - 單元測試對於理智檢查你的工作至關重要,然後再讓它出現在鯊魚坦克中。代碼覆蓋率分析是一個非常強大的工具,可以快速確定您的代碼的哪些區域永遠不會有曾被看到過,並且在發佈之前可能需要多一點關注。

使用這些工具並仔細考慮他們的結果,他們會很好地爲您服務。

0

你的問題有點奇怪。

代碼覆蓋率是顯示您的代碼在特定運行時執行多少的標準。通常人們使用代碼覆蓋率作爲評估單元測試質量的標準:在這種情況下未覆蓋的代碼等於未測試的代碼。所以,大家都希望在這裏看到100%。

在你的情況,你可以在VS2010直接使用的代碼覆蓋率以相同的目的,如果您有高級版或旗艦:http://msdn.microsoft.com/en-us/library/ms243186.aspx

對於ASP.NET應用程序,你可能想使用其他類型的測試,如UI測試(對於webforms),負載測試等,你也可以(部分)生成並直接在VS2010中運行。

2

在我的觀點中,代碼覆蓋率在進行單元測試時是一個誤導性指標。高覆蓋率並不能告訴你你有很好的單元測試。事實上,在完全沒有測試的情況下,擁有100%的覆蓋率非常容易。此外單元測試有趣的覆蓋範圍是分支機構的覆蓋面,但大多數工具可以爲您提供線路覆蓋。

你應該做的是告訴你自己TDD是如何完成的。通過適當的TDD,您可以獲得良好的單元測試,而且您無需事先考慮您的覆蓋範圍。

0

該測試使您對自己的功能和代碼覆蓋率充滿信心,使您對自己的測試充滿信心,當然代碼覆蓋率也增加了您的信心。

但是請記住,自信不是功能滿足商務,而是關於你的代碼不會意外的異常炸燬

+0

你是說單元測試只能檢查異常嗎?我認爲這很不符合單元測試的內容。 – svick

+0

對不起,我錯過了正確的短語,這可能是因爲英語不是我的母語,無論如何,我想說的是,構建應用程序涵蓋了所有編譯時錯誤,單元測試涵蓋了所有運行時可能性錯誤作爲現有的代碼覆蓋百分比。我只是想強調,高比例的代碼覆蓋率並不意味着你的應用程序是美好的,就是這樣:-) –