2010-02-18 103 views
1

我最近被要求,有效地將我的部門出售給單元測試。我無法告訴你這讓我興奮,但我確實有一個擔憂。我們在Spring和Maven中使用JUnit,這意味着每次調用mvn test時,都會重建數據庫。顯然,我們無法將其與我們的生產服務器整合 - 它會殺死有價值的數據。有沒有辦法阻止Maven測試重建數據庫?

如何防止重建瞞着行家跳過測試?

我能想出的最好的是指定的腳本在測試數據庫操作(添加爲便於閱讀,換行):

mvn test 
    -Ddbunit.schema=<database>test 
    -Djdbc.url=jdbc:mysql://localhost/<database>test? 
     createDatabaseIfNotExist=true&amp; 
     useUnicode=true&amp;characterEncoding=utf-8 

我不禁覺得必須有一個更好的辦法。

我在學習,如果有一個簡單的方法來告訴Maven的是隻在特定類別的測試,沒有建立任何東西特別感興趣? mvn -Dtest=<test-name> test仍然重建數據庫。

======= =======更新

我的臉在這裏雞蛋位。我沒有意識到我在兩個地方使用了相同的變量,這意味着POM使用「skip.test」變量來重建數據庫和運行測試...

+0

如果它接觸到實時生產數據庫,它不是一個「單元測試」 – 2010-02-19 02:18:00

+0

瞭解如何爲單元測試初始化​​dbunit和Spring將會很有幫助。 – 2010-02-19 06:43:00

回答

2

更新:我想DBUnit會重建數據庫,因爲它在測試設置方法中被告知要這樣做。如果您更改了設置方法,則可以消除DB重建。當然,你應該這樣做,以便在你需要時重置數據庫,當你不需要的時候忽略它。我的第一個選擇是使用系統屬性來控制它。您可以像在jdbc.url等人那樣在命令行中設置屬性。然後在設置方法中,您添加一個if來測試該屬性,如果已設置,則執行DB重置。

測試數據庫,從生產數據庫完全分離,絕對是最好的選擇,如果你可以擁有它。你甚至可以使用例如Derby,這是一個可以運行嵌入JVM中的內存數據庫。但是,如果您絕對不能擁有單獨的數據庫,那麼在該數據庫中至少使用一個單獨的測試模式。

在這種情況下,我會建議你把你的數據庫連接參數到配置文件的POM中,默認的是測試數據庫,和一個單獨的配置文件包含生產設置。這種方式永遠不會發生,你無意中對生產數據庫運行測試。

但一般情況下,同樣重要的是要明白,測試針對數據庫運行都算不上嚴格意義上的單元測試,而集成測試。如果您有一套現有的測試,那麼請儘可能多地使用它們。但是,您應該嘗試添加更多真正的單元測試,它們一次只測試一小部分代碼(最多隻有一個方法或類),理想情況下是自包含的(不需要數據庫,網絡,配置文件等)。 ),所以他們可以跑得快 - 這是一個非常重要的一點。如果你有5000個單元測試,每個測試只需要5秒鐘,總計可達7個小時,所以你顯然不會經常運行它們。如果一個測試只需要5毫秒,你可以在不到半分鐘的時間內得到結果,所以你可以承擔運行所有的測試,然後再提交最新的更改 - 每天多次。這對您從測試中獲得的反饋速度產生巨大影響。

希望這會有所幫助。

+0

查看更新:我需要mvn來構建類,但是我不能簡單地調用「構建和測試而不觸及(臨時/測試)數據庫」 – cwallenpoole 2010-02-18 21:58:43

1

我們對Spring和Maven使用JUnit,這意味着每次調用mvn測試時,都會重建數據庫。

Maven本身並沒有對數據庫做任何事情,你的代碼也是如此。無論如何,對生產數據庫運行測試(不是單元測試)是非常不尋常的。

如何在不告訴maven跳過測試的情況下防止重建?

硬盤沒有更多的細節,說(你不顯示任何),但型材可能是很長的路要走。

0

根據定義,單元測試只能在系統中的單個組件上運行。您不應該試圖編寫與任何外部服務(Web,數據庫等)集成的單元測試。我需要的解決方案是使用一個好的模擬框架來清除組件所具有的任何依賴關係的行爲。這鼓勵了良好的接口API,因爲大多數嘲笑框架在簡單的接口中工作得最好。最好爲與數據庫的任何交互創建一個Repository模式接口,然後在測試與其交互的類時測試impl。然後,您可以分別在功能上測試您的Repository impl。這還具有保持單元測試足夠快以保持您的CI的一部分的額外好處,以便您的反饋週期儘可能快。

相關問題