關于單元測試的一些看法 單元測試方法
從參加責任以來，參加了大大小小好幾個項目了。對于項目中間的單元測試這一項，有一些想法，不吐不快。主要縈繞以下幾個方面來說一說。(大家多多批評。)
1、對于一個項目，應該怎樣劃分在項目中需要測試的類和方式?
舉個例子，一個基于被封裝后的struts和EJB項目，哪些需要測試?在我看來，大而全是沒有必要的。
個人認為，Action的單元測試屬于對照沒有用處的一個。因為在畫面疏通的過程中，負擔者對Action的測試會更加的仔細一些，基本上能夠替代非常麻煩的Action單元測試。同時對于Form的測試在沒有特殊的方式追加的狀態下，也能夠省略掉。
然后是Dao層的測試是需要做的，但是針對非框架組成部分的成員來說，測試SQL語句應該就足夠了。CMP以及共通Dao的相關測試應該由框架來保證。
然后是service層的測試，用來做框架內部調用的代碼的測試能夠主動地無視掉，由框架開發者做出足夠的測試就能夠了。只針對業務邏輯的相關方式進行測試。在這里特別提一提設計上的一個問題。如果有通用的業務邏輯處理的話，建議直接應用工具類的形式來提供，而不要應用父類方式然后子類繼承的方式，非常的不利于單元測試。(有不贊成見的能夠批評指正。)
2、由誰來完成測試類?
我對照傾向于測試和功能代碼的負擔者不要是一個人。并且寫測試的人要比寫代碼的人更加的熟悉詳細設計。寫測試和代碼的人不一定是詳細設計者，寫代碼的人能夠看著詳細設計寫代碼，不一定要非常的熟悉設計者的思路，完成詳細設計的功能就能夠了(當然，這個是相對的)。但是寫測試的人卻要清楚的知道每一步發生了什么，輸入了什么樣的對象，得到了什么樣的對象，中間會有什么樣的處理。
首先，測試的責任量一點也不小，相對不是捎帶手就能做了的�；旧洗笠稽c的業務出現變更的時候，原先的對于該項邏輯的單元測試代碼返工量是會對照大的。如果想要做好修復BUG或者是業務變更后的單元測試，消費的時間比修復BUG和業務變更的時間長很多。對于這個說法，我不知道其他人是否也是這樣認為的?當然，在項目組長給你足夠的時間的狀態下，這個問題不是問題。
其次，當測試和功能代碼的負擔者來到之后，在項目里面，對于同一塊業務，就有了至少兩個人熟悉，不會出現只有一個人很清楚，其他人都不清楚的難堪形勢。
第三，旁觀者清的道理。寫測試的和寫功能代碼的人互相都會有想不全面的中心，有一定的互補性。這樣的測試，對照能夠測試出代碼中的冗余代碼。
3、 在責任分配中，測試代碼做成需要的時間和功能代碼做成需要的時間比例多少是相宜的?
個人認為測試和功能代碼的時間配比成2：1是一點也不過頭的。在大的業務邏輯里面，測試數據的準備需要花很長的時間。
基本上我現在接觸到的項目沒有一個符合TDD的要求。有了解TDD的前輩請對我前面的觀點進行無情的批評和打擊，謝謝。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
