介紹

我喜歡自動化測試。 在一次極少的轉移到op-ed ^1中，我想到了一些想法（閱讀–意見）。

在開始如何最好地構成您的測試之前，我先簡單問一下–測試的原因是什么？ 大致來說，我認為它們是：

1. 減少錯誤總數/提高產品穩定性
2. 確保軟件按照規范運行
3. 以低成本，低影響實現上述目標。

我認為這可以歸結為提供可以滿足客戶需求（功能），不執行客戶不想要的功能（錯誤）的軟件，并且不會造成太大的噪音（成本）。

選擇系統

選擇一個入門門檻低，人們渴望學習或已經知道的系統：

1. 在其中有價值的學習中，例如流行的行業標準，這些系統將得到更好的文檔記錄，更好的理解，更可靠，并且您的同事將更容易加入。
2. 我的意思是使用“范式”系統，即按原意使用它，而不是以異常的“范式”方式使用，這將使您的同事生活困難，并阻止采用。

您可以測試多個配置，其中某些測試僅適用于某些模塊和配置嗎？

它堅固嗎？

1. 對測試對象的更改是否容易導致識別需要更改的測試？ 對基礎實現的更改不應默默地破壞測試。
2. 避免使用完全動態的語言，編譯時檢查可防止出現印刷錯誤，并確定如果測試主題發生更改可能需要更改的測試。

考慮一下該系統對于開發人員和技術水平較低的人員是否都可以使用–您是否希望測試人員或QA能夠編寫測試？

曾幾何時，我認為這毫無疑問：測試系統是否完全自動化？ 還是，每當您運營公司時，都會花您公司的錢嗎？

寫作測試

測試應該快速運行并快速編寫：

1. 編寫測試不應要求耗時的數據庫，DLL或環境設置，而是要使這種性質的東西自動化。
2. 您不需要對定制系統的默契知識，沒有人愿意沉迷于繁瑣的手動設置。 這只是成本。
3. 問問自己–是否只需單擊一個按鈕即可進行其他人的測試？
4. 測試本身無需花費很長時間即可編寫。

不要混淆測試的生產代碼：

1. 不必擔心編寫最“有效的Java”測試代碼或重復使用。 字段不必是“私有最終”。
2. 您無需在測試中強制執行編碼標準。

測試行為，而不是方法（@Test使testMethodX無效嗎？）：

1. 考慮一個基于BDD的系統。

考慮為接口編寫測試，然后使用 參數化的運行程序，它將為每個實現運行相同的測試集。

測試失敗應明確反饋給修復程序：

1. 捕獲測試的輸出，以便可以診斷故障。
2. 確保可以將失敗的測試與其套件隔離運行，以便您專注于修復失敗的測試。
3. 測試失敗，修復錯誤的代碼和重新運行測試之間的平均時間是多長時間？

測試支持和測試雙打

文檔支持代碼：

1. 如果人們不知道測試雙打或夾具，也不會重復使用。

對于JUnit，請考慮使用@Rules為測試提供mixin- esq組件。

首選假貨：

1. 與存根，假人或模擬物相比，它們通常更具通用性和可重用性。
2. 與其他類型的雙打相比，它們將使您對主題有更好的了解。
3. 他們通常可以與實現共享一個代碼，從而進行測試。
4. 具有通過接口直接控制偽造品的能力，例如將組件置于普通API無法激發的錯誤模式，例如網絡問題或硬件故障。

偽造第三方：

1. 在我的工作中，有大量與硬件相關的JNI / JNA代碼。 通過僅偽造JNI方法，我們可以模擬各種事情，包括失敗超時。 我通過偽造串行設備，偽造javax.comm.SerialPort并用模擬失敗或其他錯誤的偽數據將其預加載來完成了類似的工作。
2. 這將與RESTful API等同樣有效。

運行測試

現實點”：

1. 最好使用真實的代碼而不是使用偽造品在具有代表性的設置上運行測試。
2. 嘗試在容器外運行測試，以便在盡可能接近生產設置的情況下運行該軟件。
3. 如果軟件在特定的環境上運行，也可以在特定的環境下運行測試，即集成測試之前要進行部署（及其隱式測試），這反過來意味著部署應該是一個按鈕。

然后使之可重復：

1. 一個人編寫的測試可以很容易地被另一個人訪問，即版本控制。
2. 無需繁瑣，容易出錯的工作即可將測試納入版本控制和單按鈕提交。
3. 它們可以在您的開發機以外的計算機上運行嗎？
4. 如果不是自動化的話，就不會重復。

與構建系統集成：

1. 測試應該在開發機器上運行，并且CI服務器和QA中的每次運行都將使您對成品更有信心。
2. 它們應該在CI中運行，可能沒有頭，并同時執行相同的測試。 他們是否使用相同的硬編碼目錄？ 他們在同一端口上監聽嗎？

參考： 測試我們JCG伙伴亞歷克斯·柯林斯在亞歷克斯·柯林斯的博客博客。