這是三個系列文章中的第一篇。

測試思路

技術技巧

工具和提示

心態

測試代碼是需要學習的東西。 需要花費時間來吸收如何做好。 這是一種應該始終練習和改進的技巧。

過去，開發人員沒有進行測試，而是檢查了他們的代碼。 這是一個很好的技巧：

檢查：代碼執行編碼人員打算執行的操作。 測試：代碼可以執行客戶所需的工作。 ＃ 敏捷 #tdd #bdd

—尼爾·基里克（@neil_killick） 2014年11月7日

今天，我們有許多工具和技術可以使用。 XUnit框架，模擬框架，UI自動化，TDD，XP…

但我相信測試始于頭腦。 心態。

為什么要測試

我真的應該回答嗎？
測試是您的代碼工具和質量保證。 測試說明了代碼的故事。 他們證明某事有效。 如果出現問題，他們會立即提供反饋。 正確使用測試可以使您更加高效。 您調試的次數更少，可能的bug更少，因此您有更多的時間進行實際工作。 您的設計將會更好（以后會更多）并易于維護。 您有信心更改代碼（重構）。 稍后會更多。 由于您對代碼更加自信， 因此可以減輕壓力 。

測試什么

我什么都說。 也許您會跳過系統的最底層。 讀取/寫入文件系統或DB或傳達某些外部服務的部分。 但是，即使這些零件也可以測試。 他們應該。 在接下來的博客中，我將介紹一些技巧。

測試最小的東西。 例如，如果您有一個DTO并決定將某個字段初始化為某個值，則進行測試，僅實例化該類，然后驗證（確認）期望值（是的，我知道，某些部分確實無法測試，但應保持最小）。

建議零售價

單一責任原則。 這就是我喜歡提到測試需要檢查一件事的觀點。 如果是單元測試，則應該測試方法/類的一種行為。 應該在不同的測試中測試不同的行為。 如果是更高級別的測試（集成，功能，UI），則適用相同的原則。 測試系統的一個流程。 測試點擊。 測試將元素正確添加到數據庫，但不能在同一測試中刪除。

隔離

隔離測試可以幫助我們準確了解出了什么問題。 開發獨立的測試有助于我們一次專注于一個問題。

隔離的一方面與SRP有關。 測試某些東西時，請將測試的代碼與其他部分（依賴項）隔離開。 這樣，你測試代碼的那一部分。 如果測試失敗，您知道是。 如果您在測試中有很多依賴性，那么很難弄清實際的失敗原因是什么。

但是隔離也意味著其他事情。 這意味著沒有測試會干擾其他測試。 這意味著測試的運行順序無關緊要。 對于單元測試，這意味著您不需要運行數據庫（或與此相關的Internet連接）。 這意味著您可以同時運行測試，而不會互相干擾（maven完全可以做到這一點）。 如果您做不到（例如：數據庫問題），那么您的測試就不會孤立。

測試氣味

如果測試難以理解/難以維護，請不要生氣！ 說：

親愛的測試人員，非常感謝您幫助我改善代碼

如果為測試設置環境太復雜，則可能是所測試的單元具有太多依賴性。

如果在運行被測方法之后，您需要驗證許多方面（驗證，斷言等），則該方法可能做得太多。 該測試可以成為您改進代碼的最好朋友 。

通常，真正復雜的測試代碼意味著結構化的生產代碼更少。 我通常會看到復雜的測試與未遵循SRP或任何其他DOLID原理的代碼之間的相關性。

可測試的代碼

這是我的最愛之一。 每當我進行代碼審查時，我都會問對方：“您將如何對其進行測試？”，“您如何知道它的工作原理？” 每當我編寫代碼時，我都會問自己同樣的問題。 “我如何測試這段代碼？”

以我的經驗，始終思考如何創建可測試的代碼會產生更好的設計。 該代碼“神奇地”具有更多的模式，更少的重復，更好的OOD且行為穩定 。

強迫自己不斷測試代碼，會讓您思考。 它有助于將大而復雜的問題分解為許多（或很少）較小，更瑣碎的問題。

如果您的代碼是可測試的且經過測試，則您對此更有信心。 對行為充滿信心，并有信心改變它。 重構它。

重構

這個項目可以是為什么的一部分。 它也可以是技術的一部分。 但是我決定特別注意它。 重構是TDD周期的一部分（但不僅如此）。 當您進行測試時，您可以確信進行重構。 我認為您在開發時需要“考慮重構”。 類似于“思考如何生成可測試的代碼”。 在考慮重構時 ，會進行測試。

重構也是一種心態。 問問自己：“我產生的代碼是否足夠干凈？ 我可以改善嗎？” （順便說一句，知道什么時候停止…）

這是有關測試的一系列文章中的第一篇。 以下文章將介紹一些測試技術和方法。

翻譯自: https://www.javacodegeeks.com/2014/11/its-all-about-tests-part-1.html

總結

以上是生活随笔為你收集整理的全部关于测试–第1部分的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。