ローカルとリモートデータベースTimeZoneの違いテストの違い

Question

ローカルテストデータベースの行に一定のタイムスタンプを書き込み、それを読み戻して予想したものと比較するJavaのunit testがあります。これは、GMTのタイムゾーンの下にある私のローカルのラップトップ上で正常に動作します。

私たちの継続的インテグレーションサーバーにコードをコミットすると、テストは-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); 

OSのタイムゾーンとは別の、または個々のDBセッションのMySQLサーバーのおかげで、

Answer 1

することができますset a timezone。前者は、UIを除き、データをインポートするとき以外はすべてUTCを使用しているので、IMOが好ましいです。

Answer 2

すべてのシステムで同じタイムゾーンを使用することをお勧めします。 UTC/GMT + 0に設定し、ユーザーまたはレポートに表示するときにのみタイムゾーンを使用します。

Answer 3

タイムスタンプをJavaで作成している場合は、モックを使用してシステムに依存しないようにすることをお勧めします。

this questionの回答を参考にしてください。

Answer 4

OK、これが最良の選択肢ではないが、なぜあなたのCIサーバーのための別の

"/dbunit/expected_insert_batch.xml" 

を作成することはできません。次に、タイムゾーンの単体テストにスイッチを追加します。

Answer 5

環境に依存しないテストを行う必要があります。このフィールドを動的にすることができる場所を探し、どこでも動作するはずです。