用於自動測試腳本的JUnit測試？

Question

我最近加入了我目前正在工作的這個組織，該組織要求我管理一個項目，以重新分解，擴展和維護現有的用Java編寫的自動測試框架，該框架使用關鍵字驅動的框架和RFT。 即使我已經轉向敏捷管理，但我一生都是一名開發人員。 按照習慣，我編寫單元測試以在編寫源代碼之前測試行為。 該框架沒有一個單元測試。 我的第一個直覺是“單元測試在哪里？” 我知道我可以為測試框架類編寫單元測試。 在這里的討論中，有人提出編寫用於測試框架或腳本的單元測試可能是浪費時間。 我在外交上不同意。

問題1：我的直覺會錯嗎？ 您有什么建議對我的案子有幫助嗎？

問題2：這可以遞歸嗎？ 為測試和測試編寫測試等等。 是否有規定何時停止編寫單元測試？ 有測試測試器遞歸的概念嗎？

同樣，我全都用於單元測試，但以前從未遇到過這種情況。 從我的研究中我找不到關於這個主題的很多東西。

編輯

謝謝大家的有趣回答！ 毫無疑問，單元測試將毫無疑問地被編寫！ 我們最常使用的自寫框架類和方法將被賦予最高優先級，這些類和方法將具有較高的投資回報率和較高的失敗懲罰率。 該計划是逐步並逐步實現整個項目的高級別代碼覆蓋率（java）

Answer 1

如果您的組織編寫了此測試框架，則應該對其進行單元測試。 如果您使用現有的測試框架（例如JUnit），那么我就不會對它進行單元測試。 將測試交給測試框架的創建者。

底線：您編寫了它，然后進行了測試。

Answer 2

肯特·貝克（Kent Beck）在軟件工程電台上接受了很好的采訪，他在演講中解釋了他在何時編寫測試，何時進行TDD等方面的理念。

他說，當他編寫一些探索性的代碼，不會共享的代碼或無法持久的代碼，尖峰解決方案時，他不會編寫測試。 他幾乎在其余時間都編寫測試。

要回答您的問題，請問自己一個問題。 如果進行了測試，它是否可以幫助您重構，擴展，維護該框架？ 如果是，編寫測試。

1）通常，優良作法建議您在重構之前（以確保行為不變）或在編寫新代碼（標准TDD）之前編寫測試。

2）是的，這可以遞歸，但是您一天中只有太多時間，因此您必須考慮為為項目帶來的額外價值而付出的努力。

編寫單元測試也可以幫助您更好地理解現有代碼。 就個人而言，我會編寫測試。

Answer 3

問題1：我的直覺會錯嗎？ 您有什么建議對我的案子有幫助嗎？

你的直覺是沒有錯的。 例如，如果您的測試框架存在錯誤，則可能會跳過測試而錯過錯誤。

問題2：這可以遞歸嗎？ 為測試和測試編寫測試等等。 是否有規定何時停止編寫單元測試？ 有測試測試器遞歸的概念嗎？

不會。因為測試用例是如此簡單，以至於錯誤無法幸免。 每個測試都應該是瑣碎的，否則被測試的類需要重構。 顯然，有時候說起來容易做起來難。

我檢查測試框架，並添加測試無論失敗會真的受傷了。

Answer 4

要測試某些東西，您需要一個參考，將其與結果進行比較。 對於框架或腳本，可以使用生產代碼作為參考-除非版本不兼容：如果所有測試都通過框架N和框架N + 1通過，則沒有[可見]回歸，所有這些限制（提供足夠的覆蓋范圍...）。 在那兒編寫用於測試框架或腳本的單元測試可能被認為是浪費時間。

現有的框架可能在大多數情況下都有效，因此花費時間進行單元測試可能是浪費。 與任何軟件一樣，在添加新功能或重做部分代碼時編寫單元測試將很有幫助。

我通常不為我的測試程序編寫單元測試，也不是為自動測試很有價值的特定部分編寫單元測試。 我將它們與生產代碼一起種植，將每個用作另一個的腳手架。

Answer 5

要考慮的另一件事是，自動化測試本身正在測試自動化測試框架。 也就是說，如果您破壞框架，則測試本身應該會失敗。 有鑒於此，投資於編寫框架本身的自動化單元測試可能沒有任何意義。