處理本地和遠程數據庫TimeZone差異的測試

我有Java的單元測試，它向本地測試數據庫中的一行寫入一個常量Timestamp，並將其讀回並將其與我的預期進行比較。這適用於GMT時區下的本地筆記本電腦。處理本地和遠程數據庫TimeZone差異的測試

當我將代碼提交給我們的持續集成服務器時，測試失敗，時間差異爲-5小時。這並不奇怪，因爲我們的集成服務器託管在美國東海岸的AWS上。然而，它造成了一個問題...

更改我的本地MySQL服務器與遠程服務器具有相同的時區（並讓我的團隊中的所有開發人員也這樣做），任何人都可以告訴我如何在代碼中解決這個問題而不會太冒昧？

//Fetch actual table contents 
IDataSet databaseDataSet = databaseTester.getConnection().createDataSet(); 
ITable actualTable = databaseDataSet.getTable("batch"); 

// Load expected data from an XML dataset 
IDataSet expectedDataSet = new XmlDataSet(getClass().getResourceAsStream("/dbunit/expected_insert_batch.xml")); 
ITable expectedTable = expectedDataSet.getTable("batch"); 

// Assert actual database table match expected table 
Assertion.assertEquals(expectedTable, actualTable);

感謝，

來源

2010-12-14 Scruffers

你應該詳細說明你如何比較時間戳，作爲整數？作爲字符串？ – Guillaume 2010-12-14 11:56:46

是的，請顯示單元測試的詳細信息:) – 2010-12-14 11:59:04

時間戳比較由DBUnit完成 – Scruffers 2010-12-14 11:59:12

您可以set a timezone爲MySQL服務器從操作系統時區分開，甚至個別數據庫會話。前者是國際海事組織的首選，因爲除了用戶界面和導入數據以外，其他地方都使用UTC。

來源

2010-12-14 11:57:57

我建議你讓所有系統都使用同一時區，例如UTC/GMT + 0，並且僅在顯示給用戶或報告時使用時區。

來源

2010-12-14 12:00:16

如果您使用Java創建時間戳，我建議使用模擬，以使其完全不依賴於系統。

請參閱this question的答案。

來源

2010-12-14 12:03:12

但我的單元測試正在測試DAO是否正確寫入數據庫。我已經寫了一個恆定的時間戳感謝模擬，但問題是，它必須通過數據庫寫入測試 - 如果時區不同，描述它會導致一個問題... – Scruffers 2010-12-14 12:08:36

對於這個問題， d主張與其他人一樣回答，只保留UTC中的所有數據庫時間並僅使用時區顯示。 – 2010-12-14 12:17:07

OK，這可能不是最好的選擇，但爲什麼不創建另一個

"/dbunit/expected_insert_batch.xml"

您的CI服務器。然後在單元測試中爲時區添加一個開關。

來源

2010-12-14 12:46:25

-1

你需要讓你的測試不依賴於環境。尋找你可以讓這個領域變得動態的地方，它應該在任何地方工作。

來源

2010-12-14 14:37:36

DAO測試總是依賴於它運行的數據庫，但我同意在一般測試中應該是環境不可知的。 – Scruffers 2010-12-15 14:55:44

處理本地和遠程數據庫TimeZone差異的測試

回答

相關問題