我覺得不是 java 單元測試的必要性，而是工程的單元測試必要性，和語言無關。

當你的項目小的時候，簡單的時候，當然單元測試沒什么用。但是如果是寫底層框架或者一些很大的項目時，單元測試對于提高生產力很有用。單元測試的好處是給人的，不是給機器的。

而且從程序設計的角度上看：單元測試可以讓你更好的拆分程序為最小單元，幫助你更好的解耦。

用到單元測試則必不可少的會用一些自動單元測試框架，對完成工程的自動化測試很有用。

光說沒什么意思，我們可以舉例子：

場景一：你有一個底層的方法，業務邏輯上有幾十上百個功能在使用這個方法。有一天，你想要給這個方法添加新的功能，添加之后到底好不好用呢？有沒有 bug 呢？如果不用單元測試，你需要把幾十上百個功能都跑一遍來驗證方法的正確性。而使用單元測試的思路，則是對這個最小單元(即這個方法)進行測試，模擬可能的輸入，看是否獲得相應的輸出，對參數的邊界做判斷等等，這就是一個簡單的單元測試了，你可以不用任何單元測試框架，自己寫就行。

場景二：你在寫一個單元(方法)，而這個單元依賴其它的方法，而這個方法的執行結果是不受控制的，我們想要可控的測試，想要這個依賴的方法的幾種執行模式都能按照預期進行，那么樁件(stub)和仿件對象(Mock)的思路就出現了 ，我們對這個依賴的方法進行仿造，使其執行后得到我們預期的結果，這樣測試過程中即使出了錯，也可以斷定不是依賴方法導致的錯誤，為開發人員減少了一部分找 bug 的時間。現在大多數的單元測試軟件、框架都有很方便的 stub、mock 接口，能很好的實現大多數測試需求。

場景三：擴展場景一的情況，你的程序架構是分層的，比如分了兩層，上層是應用層，下層是驅動層。應用層依賴于驅動層的若干方法，而且依賴關系錯綜復雜。如一個應用功能依賴了十幾個底層方法(底層方法間也有互相依賴的情況)，那么，如果這個應用功能有了 bug，那么是這個應用功能本身的代碼的問題呢，還是依賴的這十幾個方法的問題呢？還是說這十幾個方法各自依賴的其他方法的問題呢？如果人工去找，累個半死。就算找到，修改好后，發現新的修改雖然修復了原有 bug，但又引起了其他 bug，那么這個新 bug 要繼續找么？使用單元測試后，為驅動層的所有劃分為最小單元的方法都編寫測試，以最大程度(高測試覆蓋率)保證這些單元可以獨立運行成功，那么即使出了錯，修改了某個方法，也能快速的定位到 bug 和修改后對程序的影響。

拋去一大堆理論，其實單元測試最直觀的一個好處就是：當你在改了一個方法之后，跑一遍所有的單元測試，能快速的發現你有沒有把程序改成傻逼。

你可能說這個項目都是你自己寫的，你對這些程序了如指掌。但是加入別人接手你的項目，或者你接手了別人的項目呢？找 bug 時你會不會罵那個沒寫單元測試的人sb？很多的時候工程并不是一個人的玩具，需要為多人協作做一些妥協。

這么說理解了嗎？

順便這里推一下我自己的框架 WorkerA, 框架的核心部分 WorkerF 中就使用了 phpunit 做單元測試，幫我開發省了很多的時間。

總結

以上是生活随笔為你收集整理的Java单元测试的意义_关于java单元测试的作用和必要性？的全部內容，希望文章能夠幫你解決所遇到的問題。

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