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

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

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

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