単体テストの日付と時刻の書式設定で期待される結果をハードコードするのは適切ですか？

Question

私はユニットテストを非常にシンプルで簡単に続けるのが好きです。私はしばしば、テストしているコードを繰り返さないように、テスト結果をハードコードします。また、データ駆動型テストを使用することがよくあります。たとえば、日付/時刻が表示される形式をテストしている場合、予想される文字列をハードコードすることがあります。 「1/1/2000」または「1:00 PM」となります。ただし、日付と時刻の形式はカルチャ固有でアプリケーションはローカライズ可能なので、実際の出力は異なる可能性があります。しかし、私のチームは米国に拠点を置いているので、これは通常問題ではありません。私たちの継続的な統合および構築サーバーは、米国の文化情報とともに実行されます。

チームのメンバーが、自分の開発マシンで日付形式を変更して手動で他の日付形式をテストしたために不満を持ちました。単体テストで出力をテストするときに現在のカルチャ情報を使用しているか、このハードコーディングが受け入れられていますか？

更新：特定のテストで特定のロケールを設定しました。

Answer 1

ユニットテストは、実行環境に関係なく、100％反復可能でなければなりません。単体テストが失敗する唯一の理由は、コードが変更され、テストが壊れたためです。

はい、外的要因にかかわらずテストが確実に成功するようにする必要があります。

Answer 2

結果をハードコードすることはもちろんですが、単体テストが環境から隔離されていることを確認するために、ロケール情報のtest-doubleを指定する必要があります。

他の開発者のロケール設定をエミュレートするtest-doubleで新しい単体テストを追加することもできます。

ユニットテストは、どのマシンでも実行して渡す必要があります。

Answer 3

理想的には、ローカライズをピン止めする別のテストスイートが必要です。現在の文化のテストが行​​われる限り、私の最初の選択は、オペレーティングシステムによって提供されるデフォルトに頼るのではなく、特定のロケールをテスト実行環境に強制することです。これが不可能な場合は、メインシステムでのローカライゼーションの処理方法と同様に、現在のロケールで単体テストをパラメータ化し、そのローカライズ可能なストレージから期待値を読み込みます。重要な点は、ホストコンピュータの設定を切り替えるだけで、ユニットテストスイートを停止することができないということです。