我和我追逐的夢
在單元測試中,通常我們都會有一個明確的測試對象,我們測試的主要目的就是為了驗證這個類的工作如我們預期。
以下面的簡單代碼為例:
這里我們定義有兩個interface: UserService 和 UserDao, 并給出了兩個實現類UserServiceImpl 和 UserDaoImpl。 其中UserServiceImpl依賴到UserDao,通過setter方法可以注入一個UserDao實現。而UserDaoImpl的實現則依賴到Datasource。
然后我們來為實現類UserServiceImpl 和 UserDaoImpl編寫單元測試:
1. UserServiceImplTest
在這個測試類中,主要測試對象就是UserServiceImpl,對于UserServiceImpl的依賴UserDao,我們采取mock這個UserDao來滿足UserServiceImpl的測試需要。
2. UserDaoImplTest
代碼示例就不詳細寫了,和上面的類似,主要測試對象就是UserDaoImpl, 我們將通過mock Datasource來滿足UserDaoImpl對datasource的測試需要。 可以從上面的例子中簡單的看出,通常單元測試都遵循這樣的慣例: AClass的單元測試類命名為AclassTest,主要職責是測試AClass的行為,理所當然的主要測試對象就是AClass。而所有被AClass的依賴則自然而然的成為次要測試對象,通常我們都不關注這些依賴的內部實現,也不會要求在AClass的單元測試案例中對這些依賴的實現進行測試和驗證。 這也符合單元測試的理念: 我們將類AClass定義為單元,測試這個單元的行為是否如預期。同時也符合UserServiceImpl的實現邏輯:UserServiceImpl依賴到UserDao接口,并不直接依賴到UserDaoImpl,因此在UserServiceImpl的單元測試中,也不應該引入UserDaoImpl這樣的真實類,mock框架在這個時候是最適合出場表演的了:我們可以通過mock UserDao來模擬出UserDao的各種行為以便檢測UserServiceImpl在這些行為下的處理是否正確: 不同的返回值,錯誤場景,異常場景。這也是mock框架在單元測試中被廣泛使用的原因:還有什么比mock 類更能方便的做到這些?
posted on 2010-10-14 14:01 sky ao 閱讀(1732) 評論(0) 編輯 收藏 所屬分類: software test
Powered by: BlogJava Copyright © sky ao