I have unit test in Java that writes a constant Timestamp to a row in my local test database, reads it back and compares it to what I expected. This works fine on my local laptop which is under the GMT timezone.
When I commit the code to our continuous integration server, the test fails with the different in time being -5 hours. This is no surprise since our integration server is hosted on AWS on the East Coast of US. However, it is causing a problem...
Short of changing my local MySQL server to have the same timezone as the remote server (and having all the developers in my team do so also), can anyone show me how to fix this issue in code without getting too hacky?
//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, actualTabl开发者_Go百科e);
Thanks,
You can set a timezone for the MySQL server separate from the OS timezone, or even for individual DB sessions. The former is IMO preferable, as is using UTC everywhere except for the UI and when importing data.
I suggest you make all your systems use the same time zone e.g. UTC/GMT+0 and only use the timezone when displaying to a user or in reporting.
OK, this may not be the best option, but why not create another
"/dbunit/expected_insert_batch.xml"
for your CI server. Then add a switch in your unit test for timezone.
If you're creating the timestamp in Java, I recommend using a mock so that it isn't system-dependent at all.
See the answers to this question for ideas.
You need to make your test not depend on environment. Look for places where you can make this field dynamic and it should work anywhere.
精彩评论