摘要: 做java企業(yè)級開發(fā)時，我們通常采用三層架構(gòu)。特別地，如果我們要做的系統(tǒng)的業(yè)務(wù)邏輯不是很復(fù)雜時，我們要處理的不過是CRUD操作，這時我們可能將dao層與service層合并為一層，盡管很多人會這樣做，但我仍傾向于將兩層分開；因為service與dao不是一一對應(yīng)的，從復(fù)用及邏輯清晰的角度考慮，應(yīng)該將它們分開。在三層架構(gòu)下，對于web層，service層，dao層我們都該怎么測試？這里我將介紹基于Spring，Hibernate和DbUnit的情況下我的測試方法。由于使用了Spring，事務(wù)管理就不在dao，因此要單獨地測試dao可能要麻煩一些；另一方面，dao中的操作大多是簡單的，也不是很值得測試。在使用了Hibernate和Spring的情況下，我們要測試的除了HQL，還有其配置文件，我覺得對數(shù)據(jù)持久化的測試最好定在service上。如果service業(yè)務(wù)邏輯復(fù)雜的話，與數(shù)據(jù)持久化無關(guān)的業(yè)務(wù)邏輯（應(yīng)該寫在領(lǐng)域?qū)ο笾校┛梢詥为殰y試，在保證與數(shù)據(jù)持久化無關(guān)的業(yè)務(wù)邏輯的正確性下，帶上dao操作做集成（單元）測試。  閱讀全文

     摘要: 在做Java企業(yè)程序的時候，不可避免地要和外部資源打交道，比如數(shù)據(jù)庫，Http請求等。對于這些外部資源的處理，我們可采取的操作或者是直接處理或者是模擬處理。當(dāng)我們使用Webwork，Spring，Hibernate等框架時，我們要測試的并不僅僅是Java代碼，我們還要測試依賴于這些框架的配置文件等等。因此，對于數(shù)據(jù)持久化的測試，Mock方法是行不通的，我們需要真實地測試數(shù)據(jù)庫操作。對于持久化測試來說，重要的是創(chuàng)造出已知的“干凈的”的準(zhǔn)備數(shù)據(jù)。如果我們在測試一個持久化方法前不能確定數(shù)據(jù)庫到底存著什么數(shù)據(jù)，我們只能通過反復(fù)地查看數(shù)據(jù)庫數(shù)據(jù)來驗證測試方法的正確性了（這就是我和大多數(shù)人以前使用的最“直接”的方法）?，F(xiàn)在就讓我們使用DbUnit，來更好的更自動化的測試持久化操作吧！

先介紹一下DbUnit。DbUnit是一個 JUnit擴(kuò)展，適用于數(shù)據(jù)驅(qū)動的程序。使用DbUnit，可以在測試運行期間將數(shù)據(jù)庫的數(shù)據(jù)處于已知狀態(tài)，這樣在測試時可以方便地寫出測試斷言，也能自動地完成對數(shù)據(jù)持久化方法的測試。在使用上，DbUnit也很簡單， 它提供了大量的  閱讀全文

     摘要: 我們應(yīng)該如何以及在哪里使用Mock對象呢？一般來說，對于目標(biāo)對象中的合作者對象，在測試時如果其狀態(tài)或行為的實現(xiàn)嚴(yán)重地依賴外部資源（比如數(shù)據(jù)持久化中的DAO，比如負(fù)責(zé)發(fā)送電子郵件的類），或者團(tuán)隊并行開發(fā)時，目標(biāo)對象的合作者對象并沒有實現(xiàn)（比如J2EE中，橫向分工時，負(fù)責(zé)Action的調(diào)用Service，負(fù)責(zé)Service調(diào)用DAO時，相應(yīng)的Service及DAO沒有實現(xiàn)），這時我們就需要模仿這些類。其實，在做J2EE時，傳統(tǒng)的N層架構(gòu)中，我們都是面向接口編程的，我們定義了DAO接口，我們定義了Service接口，這樣做的優(yōu)點就是我們在測試時可以構(gòu)造實現(xiàn)接口的Mock類。這里不得不提依賴注入，通過依賴注入，我們才能在測試時set Mock對象。這也說明，為了方便測試，我們不得不一步一步重構(gòu)代碼，而模式就在重構(gòu)中自然地產(chǎn)生了。
  閱讀全文