2010-04-07 63 views
9

我對以下方案特別感興趣。假設您有編寫生產代碼的團隊和編寫自動測試的團隊。編寫自動測試的團隊有專門的框架來編寫自動測試。測試團隊是否應該爲其框架編寫單元測試,儘管該框架未用於生產?你對非生產代碼進行單元測試嗎?

回答

4

我已經在這種情況下,什麼我所做的是使用測試套件產品代碼也可作爲測試套件的測試框架。據推測,該框架的所有功能都是實際使用的,所以如果測試失敗而沒有更改生產代碼,那麼測試框架中必定存在問題。

它工作正常 - 運行這些測試花費的時間比專用測試測試套件要長得多,有時我不會運行所有這些測試,並且在生產構建服務器上出現問題。診斷這些問題花費的時間比測試測試套要長得多。總而言之,我從來沒有對它感到滿意,並且真的會推薦爲測試框架進行專門的測試。從測試團隊的角度來看,測試框架的產品代碼是。如果測試框架被任何其他人使用,其測試套件無法訪問...

1

是的,如果只是爲了測試框架產生足夠的測試覆蓋率。

4

地獄是!

TDD爲您提供開發優勢,不僅僅是爲了取悅客戶。它允許你編寫可測試的,可重用的和模塊化的代碼。我會單元測試一切必須工作的東西,特別是如果您希望經常更改它(重構添加新功能)。

2

測試團隊應該盡一切可能增加他們對框架所提供結果的信任。

這包括測試,代碼審查,質量標準,...

0

這個問題讓我想起了一個故事:曾幾何時有一家公司。該公司相信自動測試。這種信念如此強烈,導致創建一個團隊,其唯一目的就是編寫這些自動測試。所有最熱心的信徒都被允許加入這個組織。有很多歡樂!

然後有一天,發現這個自動測試組儘管有其使命,但並沒有爲自己的工作使用自動測試。石頭鑄造,亞達亞達。


我只是說...我認爲任何測試框架都會有非常穩定的測試覆蓋率。

+0

你可以這樣看我的問題。但是我認爲根據這個論點決定測試非生產代碼是天真的。維護測試最終會花錢,而且我個人認爲您應該只測試自動化框架,而不是測試自動化實驗室的每一個位置。另一方面,在生產代碼中,您的目標是儘可能多地進行測試。這是我的問題的原因。 – Ikaso 2010-04-11 07:35:04

+0

我正在翻轉,但我的觀點是可以應用相同的評估標準。爲什麼我們編寫自動化測試,即使他們可能會將開發成本增加15%? 最後,答案是_因爲它增加了我們對code_的信心。這不是黑色和白色 - 問題是我們應該再寫1個測試嗎?如果我們已經對代碼有信心,或者信心不是那麼重要,那麼就沒有必要編寫測試。無論軟件的消費者是商業客戶,開發人員還是我的小弟弟,我都會遵循該指南。 – ndp 2010-04-11 15:23:34