2008-12-15 116 views
5

我有大約100個單元測試,覆蓋率爲20%,我試圖增加覆蓋率,並且這是一個開發項目,因此不斷添加新的測試。如何處理長時間運行的單元測試?

目前在每次構建後運行我的測試是不可行的,他們需要大約2個時刻。

測試包括:

  • 文件從測試文件夾讀取(數據驅動的風格,以模擬一些HTTP的東西)
  • 做實際的HTTP請求到本地Web服務器(這是一個巨大的痛苦,嘲笑,所以我不會)
  • 不是所有的單元測試,但也有相當複雜的多線程類需要測試,我做測試的整體行爲。這可以被視爲功能測試,但也需要每次運行。

多數功能需要讀取HTTP,TCP做等等。我無法改變他們,因爲這是項目的整體思路,如果我改變這些測試將是毫無意義的測試的東西。

另外我不認爲我有最快的工具來運行單元測試。我目前的設置使用VS TS與Gallio和nUnit作爲框架。我認爲VS TS + Gallio比其他人慢一點。

你會推薦我解決這個問題嗎?我想在每一點變化btu後運行單元測試,目前這個問題正在中斷我的流程。

進一步明確編輯:

守則高度耦合的!不幸的是,改變就像一個巨大的refatoring過程。還有一個雞蛋綜合徵,我需要單元測試來重構這樣一個大代碼,但是如果我不重構它,我不能再進行更多的單元測試:)

高度耦合的代碼不允許我將測試分割成更小的塊。此外,我不測試私人的東西,這是個人的選擇,這使我能夠更快地發展,並且仍然獲得大量的好處。

而且我可以確認實際上所有的單元測試(具有適當的隔離)相當快,並且我沒有與它們的性能問題。


進一步明確:

代碼被高度耦合!不幸的是,改變就像一個巨大的refatoring過程。還有一個雞蛋綜合徵,我需要單元測試來重構這樣一個大代碼,但是如果我不重構它,我不能再進行更多的單元測試:)

高度耦合的代碼不允許我將測試分割成更小的塊。此外,我不測試私人的東西,這是個人的選擇,這使我能夠更快地發展,並且仍然獲得大量的好處。

而且我可以確認實際上所有的單元測試(具有適當的隔離)相當快,並且我沒有與它們的性能問題。

回答

10

這聽起來不像單元測試,但更像功能測試。這很好,自動化功能測試很好,但功能測試很慢很常見。他們正在測試整個系統(或其大部分)。

單元測試往往是因爲他們脫離一切測試一兩件事要快。如果你不能與其他所有東西隔離地進行測試,你應該考慮你所編碼的警告標誌太緊密耦合

你能說出哪一個考驗你有哪些是單元測試(測試1米的東西)與功能測試(同時測試2個或更多的東西)?哪些是快速的,哪些是慢的?

+0

所以我假設正確的舉措是:重構代碼的方式,我沒有這麼多的耦合。然後每天運行功能測試,但在每次構建之後運行單元測試? – 2008-12-15 15:29:24

+0

另外我已經更新了有關您的答案的問題。 – 2008-12-15 15:30:02

+0

您甚至可以使用持續集成在每次簽入時運行所有功能測試。當我編寫單元測試時,我傾向於頻繁地運行那些本地的工作,然後再運行較少的集合,以及我提交之前的所有工作。 – 2008-12-15 16:00:48

7

你可以分割你的測試分爲兩個組,一個用於短期測試,一個用於長時間運行的測試,並運行長時間運行的測試不那麼頻繁,同時運行的每一個變化後的短期測試。除此之外,嘲笑來自Web服務器的響應以及您的應用程序所做的其他請求將導致更短的測試運行。

3

首先,那些不是單元測試。

沒有太多的每一個細小的變化之後運行這樣的功能測試點。經過相當大的改變後,你會想要運行你的功能測試。

其次,不要害怕嘲笑應用在HTTP部分。如果你真的想單元測試它的應用程序必須。如果你不願意那樣做,你會浪費更多的時間來測試你的實際邏輯,等待HTTP請求返回並嘗試設置數據。

我會保持你的集成水平測試,但力求打造真正的單元測試。這將解決您的速度問題。真正的單元測試沒有數據庫交互或HTTP交互。

1

我總是使用「LongTest」類別。這些測試每天晚上執行,而不是白天執行。這樣可以減少很多等待時間。嘗試一下:將你的單元測試分類。

1

這聽起來像你可能需要管理開發團隊的期望。

我假設人們每天都在做幾次構建,​​並且在每次構建之後都會運行測試。我們可以很好地服務於切換測試計劃,以在午餐時間進行測試,然後在晚上進行測試。

我同意布拉德這些聽起來像功能測試。如果你可以將代碼分開,那很好,但在那之前我會切換到不太頻繁的測試。

7

我會推薦相結合的辦法,以您的問題:

  • 經常運行接近你的更改(從同一封裝,模塊或類似的例子測試)的代碼測試的一個子集。不太經常運行的測試,它們遠離您當前正在使用的代碼。
  • 將您的套件至少分成兩部分:快速運行和慢速運行測試。更頻繁地運行快速運行測試。
  • 考慮讓一些不太可能失敗的測試僅由自動化的繼續集成服務器執行。
  • 學習提高測試性能的技巧。最重要的是通過更快的假貨取代較慢的系統資源。例如,用於內存流而不是文件。存根/模擬http訪問。等等。
  • 瞭解如何使用低風險依賴打破技術,如(非常高度推薦的)「使用遺留代碼有效工作」一書中列出的技術。這些允許您在不應用高風險重構的情況下有效地使代碼更易於測試(通常通過暫時使實際設計變得更糟,例如破壞封裝,直到您可以使用測試安全網重構更好的設計)。

一個我上面提到的書中學到的最重要的事情:沒有魔法,與遺留代碼工作是疼痛,始終疼痛。你所能做的就是接受這個事實,並盡你所能緩慢地擺脫困境。

相關問題