ロケール固有の単体テストにはどのようなプラクティスがありますか？

最近、アプリケーションでロケール固有の問題を発見しましたが、修正は簡単でしたが（何が起こっているのかがわかった後）、この点で単体テストの実践について考えているチームが見つかりました。

これらの問題をできるだけ早く、理想的には顧客が発見する前にキャッチし、将来ロケール固有のバグを再導入しないように保護したいと考えていますが、少なくとも1つの他の文化ですべてのユニットテストを複製することは多くのようですオーバーヘッド。

どのように、またはどのようにマルチロケール単体テストにアプローチしますか？

通常、すべての単体テストを複製する必要はありません。実際にロケールに依存しているものを特定する必要があります（適切なチェックリストはこちら）。国際化に関連する多くのことは、単体テストよりも高いレベルのテストの対象となります。

異なるエンコーディングの文字列データを扱う場合、「データ駆動型テスト」を利用できます。つまり、異なるエンコーディングのデータを同じテストメソッドに渡すことができます。Javaの場合、TestNGはこれに最適です。

別の考えられる問題は、日付/時刻のフォーマットと解析です。ほとんどのロケールは、時間要素を区切るために：を使用しますが、ドットを使用し、ブラジル人はhmとs（12h15m30s）を使用します。これは、異なるロケールで渡されたデータでも使用できます。すべてのロケールをテストする必要はありません。

また、右から左へのロケールでGUIをテストすることは、通常、ユニットテストの対象ではありません。

一番下の行は、ユニットテストでロケール固有のデータを特定し、データ駆動テスト（データプロバイダー）を使用してこのデータをテストに提供する必要があるということです。

以下にいくつかの提案を示します。

• 常に、メインのターゲットオーディエンスとは異なるローカル設定のマシンで開発してください。これは、日付、通貨、およびすべての数値フォーマットの問題に関連するバグを非常に迅速に見つけるのに役立ちます。ビルドサーバーでも同じことを行い、ブラジルまたはベトナムに配置します（物理的にではなく、設定のみ）。

• ユニットテストのテストタイトル、文字列などでアクセントと特殊文字を使用します。私が使用しているソフトウェア（開発しているソフトウェアではない）で最も一般的な国際化の問題は、フランス語のéおよびèまたはçにさえあります。テストで使用するすべての文字列に入力します。いつも使っている一般的な言葉を使いますbrèç©

• パスでもアクセントと特別なチャートを使用することを忘れないでください。Visual Studio.NET自体にはまだ多くの問題があります！このようなディレクトリの作成にアクセスし、テストでそれらのディレクトリから読み取り/書き込みを行う必要があります。

• Visual Studio .NETを使用する場合、プロジェクトプロパティの[ コード分​​析]で、グローバリゼーションルールを有効にします。最も一般的な問題は、コンパイル時に警告を生成します。

• チームで外国人を雇います。