2012-03-30 30 views
7

在下面的代碼的問題是,我無法測試dao.add()不使用dao.list()。大小(),反之亦然。如何在不使用「查找」的情況下測試DAO中的「添加」?

此方法是正常還是不正確?如果不正確,如何改進?

public class ItemDaoTest { 

    // dao to test 
    @Autowired private ItemDao dao; 

    @Test 
    public void testAdd() { 
     // issue -> testing ADD but using LIST 

     int oldSize = dao.list().size(); 
     dao.add(new Item("stuff")); 
     assertTrue (oldSize < dao.list().size()); 
    } 

    @Test 
    public void testFind() { 
     // issue -> testing FIND but using ADD 

     Item item = new Item("stuff") 
     dao.add(item); 
     assertEquals(item, dao.find(item.getId())); 
    } 
} 
+0

您是在集成或單元測試之後? – davidfrancis 2012-03-30 22:44:19

+0

你告訴我:)在這種特殊情況下 - 只使用常識似乎更像是對我的集成測試。但是,你知道,畢竟我只是想確保我的DAO工作,就是這樣。 – Xorty 2012-03-31 01:18:19

+0

是的,這是一種痛苦。由於dao具有的依賴性,不確定是否可以結束單元測試。 dao如何工作?我會親自嘗試避免讓你的測試依賴於外部數據庫,並嘗試存根或模擬數據庫訪問層,如其中一個答案中的建議。話雖如此,但它從來沒有像真正的分貝依賴集成測試那樣令人放心。 – davidfrancis 2012-03-31 10:21:18

回答

2

我認爲你的測試是有效的集成測試,如上所述,但我會用Add來幫助測試Find和反之。 在某些級別上,你必須允許自己將信任放在最低級別整合到你的外部依賴。我意識到在測試中存在對其他方法的依賴關係,但我發現Add和Find方法是非常容易驗證的「低級」方法。他們基本上是相互檢驗的,因爲他們基本上是反方法。

添加可以輕鬆地構建先決條件找到

查找可以驗證一個附加成功。

我不認爲其中任何一個故障就不會被你的測試

0

我使用直接JDBC(使用Spring的JdbcTemplate)來測試DAO方法。我的意思是我調用DAO方法(這是Hibernate基礎),然後使用JDBC直接SQL調用來確認它們。

+1

但是這意味着僅僅爲了測試而添加未經測試的JDBC代碼行......:| – Xorty 2012-03-30 20:46:41

1

你testAdd方法有一個問題:它取決於ItemDao.list功能正常,然而ItemDao是你正在測試的類的假設。單元測試意味着獨立,所以更好的方法是使用普通的JDBC -as @Amir表示 - 來驗證記錄是否在數據庫中引入。

如果你使用Spring,你可以中繼上AbstractTransactionalDataSourceSpringContextTests訪問JdbcTemplate的設施,並執行測試後保證回退。

0

最小的單元測試抓到基於類的單元測試場景的一類。

想知道爲什麼,認爲你可以,理論上,通過繞開,測試框架或者模擬測試這些類的每個方法脫離所有其他方法。有些工具可能不支持;這是理論不實踐,假設他們這樣做。

即便如此,做的事情,這樣會是一個壞主意。單獨的功能本身的規範將在模糊的無意義和冗長的不可理解之間變化。只有在不同函數之間的交互模式中,纔會存在比可以用來測試它的代碼更簡單的規範。

如果您添加項目,並報告增加項目的數量,一切正常。如果有某些方法可能無法正常工作,但所有交互模式都成立,那麼您就錯過了一些必要的測試。

相關問題