談談 Java 單位測試（UT）的一些準則

F.I.R.S.T 準則

• 快速（Fast），測試應該充足的快。測試應該可以快速運轉，運轉慢，你約莫不太想經常地運轉，也不克不及盡早地發覺成績，也無法容易修正。
• 獨立（Independent），測試應該互相獨立。某個測試不應該為下一個測試設定條件。你應該可以獨立運轉測試，以及以任何排序來運轉測試。當測試互相依托時，某一個測試不經過時，會招致其他測試用例也無法經過。
• 可反復（Repeatable），測試應對可以在任何情況中反復經過。好比：你可以在有網絡的情況中測試經過，也可以在無網絡的情況中測試經過；FAT 情況中可以測試經過，PROD 情況中也可以測試經過。假如有情況依托，當情況不具偶爾你就沒法去運轉你的測試用例。
• 自足驗證（Self-Validation），測試應該有 bool 值輸入。無論經過或失敗都不發起經過日志文件來確定測試對否經過。假如測試不克不及自足驗證，對測試運轉后果的推斷就變得依托臆斷，并且運轉測試也必要更多的手工利用時間。
• 及時（Timely），測試應該及時去編寫。我們編寫 UT 的目標就是要確保消費代碼的質量，假如沒有 UT 的保證，就像是裸奔。代碼公布消費前必需確保有 UT 并且 UT 的種種掩蓋率必需達標。事后去補 UT 就丟失了其本身的意義。

A.I.R 準則

• A（Automatic）主動化，單位測試應該是全主動實行的，測試用例經過會被經常地實行，實行歷程中必需完全主動化才故意義。假如單位測試的輸入后果必要人工到場反省，那么它一定是不及格的。單位測試中不允許經過 System.out 來舉行人工驗證，而必需經過斷言來驗證。
• I（Independent）獨立性，為了確保單位測試的安定性、可靠性和可維護性，必要確保其獨立性。
• R（Repeatable） 可以反復，測試應對可以在任何情況中反復經過。

B.C.D.E 準則

• B（Border），界限值，包含循環界限、特別取值、特別時間點、數據排序等。
• C（Correct），準確的輸入，并取得預期的后果。
• D（Desgin），與計劃文檔相團結，來編寫單位測試。
• E（Error），單位測試的目標來證實步驟有錯，而不是步驟無錯。為了發覺代碼中的潛伏的錯誤，我們必要在編寫測試用例時有一些欺壓的錯誤輸入，包含但不限于：不法數據、特別流程、非業務允許等。