重構測試代碼的最佳實踐

我目前在QA中有一份工作，在我的公司中，每個人都在QA中編寫自動化測試。最近我一直在閱讀Martin Fowler的Refactoring: Improving the Design of Existing Code。我意識到，我們的很多測試類和測試工具非常混亂，多餘，並且迫切需要重構。重構測試代碼的最佳實踐

特別是因爲我一直在讀這個話題，所以我渴望潛入並清理乾淨的東西，但是有一個問題。在他的書中，Fowler強調單元測試重構下的代碼對於防止引入錯誤至關重要。由於我試圖重構的代碼是測試代碼，因此單元測試似乎很愚蠢。你們有沒有對如何重構甚至設計測試代碼的建議？此外，如果它有幫助，我們使用的測試框架建立在JUnit之上，因此我所指的測試類是TestCase的後代。

謝謝！

來源

2011-04-15 Paul Keene

關於你的第一個陳述。我認爲紅色，綠色，重構循環中的一個常見誤解是，重構僅在您的代碼被測試。編寫可維護測試的一個非常重要的部分就是確保將重構測試作爲重構週期的一部分，並牢記DRY。在測試構造器之後，我總是做的第一個重構是提取工廠方法來創建被測對象。 – Andrew 2011-04-15 06:01:11

不，這不完全正確。重構因子的技巧是能夠驗證您是否保留了功能。

您需要確保所有更改在之前和之後進行了驗證。這並不是真的。但是，您不需要爲該代碼編寫自動化測試，但可能會有所幫助。

對測試代碼進行復雜重構的訣竅是能夠針對被測系統運行測試並獲得相同的結果。

所以實際上可驗證性是確保輸出是相同的。這應該是自動的。您可以通過多種方式來完成此操作，但最簡單的方法就是輸出您正在運行的測試以及您所期望的輸出和您收到的輸出。

可能你可以使用像XML這樣的機器可讀格式來更容易解析。

來源

2011-04-15 05:47:06

我同意上一篇文章，您應該在修改套件實現之前和之後運行測試套件，以驗證它的功能是否相同。

您還可以使用更簡單的單元測試框架對單元測試進行單元測試。如果你的代碼繼承自JUnit，那麼使用JUnit來測試它。至少你必須假設JUnit工作。

來源

2011-04-16 00:42:20 Dabowheel

重構測試代碼的最佳實踐

回答

相關問題