在軟件開發(fā)人員抱怨單元測試的眾多原因中，處理嘈雜的測試套件是最大的原因之一。而且，某個軟件存在的時間越長，它的噪音就越大。

為了明確起見，“噪音”是指不斷失敗的測試，但是無論如何您都知道（認為）還可以，所以就順其自然。或有時會失敗且有時會起作用的測試，但沒有人曾費心找出或修復(fù)它們。然后，由于代碼已更改并且需要更新測試，因此某些測試確實失敗了。所有這些噪音只是為了引起我們的注意而尖叫，但要注意的是，噪音越大，我們對它所做的任何有意義的事情就越不可能。

但猜猜怎么了？那些“失敗但可以通過”的測試中的某個地方是您希望知道的一些實際問題。認為它就像嘗試使用拼寫檢查器一樣。如果您不堅持下去，將會得到您不關(guān)心的所有東西，例如特殊的行業(yè)用語，名稱等，這些都不是真正的拼寫問題。但是，隱藏在混亂中的某個地方卻是您實際上犯下的令人尷尬的錯誤-您想要從那里出來的愚蠢的拼寫錯誤的單詞。當然，全球存在大量錯誤的拼寫錯誤-但是與您的軟件不同，那里并沒有很多內(nèi)在的風險，只是有些尷尬。

但是，單元測試套件通常處于相同狀態(tài)。我們習(xí)慣于看到和忽略很多嘈雜的結(jié)果，不幸的是隱藏了我們需要知道和理解的真實結(jié)果。在許多組織中，要解決此問題，有人會不時安排一次沖刺以清理測試套件，時間間隔從幾個月到幾年。花費大量時間使套件盡可能人性化，但不可避免地問題很快就會回來，而且比您預(yù)期的要快。這會形成一個負面的反饋循環(huán)——沒有人希望清理測試，因為他們認為下次會再次變得嘈雜。

答案是采用一種更實用的方法-從一開始就消除乏味，無用的清理沖刺，并避免使用嘈雜的測試套件。

盡量減少嘈雜的測試套件

為此，重要的是要了解單元測試失敗時的含義。它歸結(jié)為三個原因，并提供了簡單的修復(fù)程序：

1. 代碼已損壞。因此，請修復(fù)代碼。（理想情況下，這是干凈的測試套件告訴您的內(nèi)容。）

2. 代碼已正確更改，現(xiàn)在測試已中斷。因此，請修復(fù)測試以匹配新代碼。（如果您的代碼正在更改，則可以預(yù)期會發(fā)生這種情況。在處理代碼時，有充分的理由進行測試。）

3. 測試是錯誤的，代碼很好。因此，請修復(fù)測試。（或者刪除它。但是關(guān)鍵是–不要忽略測試。）

現(xiàn)在。您可能在想–如果我的大量測試用例適合該第三類呢？這有什么幫助？因此，讓我們分解一下。

產(chǎn)生噪聲的原因通常歸結(jié)為一些基本問題：不良測試，脆弱測試或不良主張。不良測試是指無法正常工作的測試。他們正在進行比他們應(yīng)有的測試更多的東西，或者他們懸掛的數(shù)據(jù)不一致或可能因外部條件而發(fā)生變化。

為了將噪音降到最低，請確保對于每一個給您帶來問題的測試（或者更好的是所有測試），您都能很好地回答以下兩個簡單問題：

1. 測試通過意味著什么？

2. 測試失敗意味著什么？

如果對于任何測試，您對這兩個問題都沒有合理的答案，則需要改進。

改善脆弱性測試

易碎測試是那些容易打破的測試。同樣，這通常是懶惰斷言的征兆-僅檢查事物（因為可以對其進行檢查）并不意味著應(yīng)該對其進行檢查。每個斷言應(yīng)具有與要測試的代碼滿足的要求有關(guān)的真實含義。常見的罪魁禍首包括對日期/時間敏感的斷言，操作系統(tǒng)依賴性，文件名/路徑依賴性，第三方軟件安裝，合作伙伴API等。請確保您僅斷言為進行良好測試所需的最低要求，并確保測試所需的一切都是源代碼控制和構(gòu)建系統(tǒng)的一部分。

其他錯誤的斷言要么是持續(xù)處于故障狀態(tài)，要么您不介意放開（“噢，別無所求，不要擔心”），或者處于不斷變化的狀態(tài)（“以前很好，昨天失敗了，但是今天很好！”）如果代碼不斷變化，可以在短時間內(nèi)獲得不斷變化的結(jié)果，但是從長遠來看，這是不可接受的。您需要了解為什么測試結(jié)果一直在變化，或者肯定為什么您認為可以失敗并仍然可以發(fā)布。對單元測試（包括斷言）進行同行評審將大大有助于永久解決此問題。（同行評審的另一個好處是？如果您處于合規(guī)環(huán)境中，測試是強制性監(jiān)督的一部分，那么生存起來就容易得多。） 

評估損壞的測試確實是進行大多數(shù)清理工作的好地方。我想請您認真檢查失敗了幾個月甚至幾年的測試。問問自己，他們是否真的在增值。記住，您還是會忽略結(jié)果，所以說實話它們有什么用？刪除您忽略的測試將使您可以將精力集中在重要的測試上，并實際上提高了總體質(zhì)量。

因此，它變得相當簡單（盡管可能需要花費最初的時間）。要進行清理，只需遵循以下最佳實踐：

• 定期運行測試，以確保它們不會過時——使用代碼進行測試。

• 刪除始終失敗的測試，或?qū)ζ溥M行修復(fù)。

• 刪除不斷翻轉(zhuǎn)狀態(tài)（通過/失敗）或擰緊測試的測試。

• 同行評審單元測試。

當然，不要忘記使用自動化來完成繁瑣的工作，從而使您花在編寫測試上的時間更有效率，從而使您可以創(chuàng)建噪音較小的測試。

使用測試自動化

利用自動化軟件測試的優(yōu)勢，可以減少單元測試的工作量。如果您可以讓自動化完成簡單繁瑣的部分（計算機擅長的部分），那么您就可以騰出時間來做需要實際的人類智慧（您擅長的事情）的事情。例如，讓自動化創(chuàng)建您的xUnit測試用例的第一個工作通過（做起來非常繁瑣的簡單代碼）。如果讓工具自動生成吸氣劑/裝甲劑測試方法，則可以節(jié)省大量時間，可用于其他更有趣的事情。 

當我們對測試自動化變得更加復(fù)雜時，工具可以提供更多的幫助，進行單元測試中一些棘手的部分，例如創(chuàng)建和配置存根和模擬。您利用自動化的機會越多，單元測試所花費的時間就越少，也將減少很多乏味。如果您使用的是Java，請查看集成在Parasoft Jtest中的新的單元測試助手。它可以做所有這些事情，甚至更多，這使得單元測試不僅更加容易，而且更加令人愉悅。