テストデータはどこに保存すればよいですか？

実際のデータセットからの小さなスニペットを使用する小さな単体テストがあります。また、さまざまな理由から、完全なデータセットに対してプログラムをテストしたいと思います。唯一の問題は、単一の実際のデータセットが約5GBであることです。Gitリポジトリーに保管できる具体的な数値は見つかりませんでしたが、多すぎるようです。

このプログラマーの投稿によると、プロジェクトをテストするために必要なすべてのデータをリポジトリーに保管する必要があります。

私のチームが採用したソリューションは、プロジェクトに、テストデータを保持するネットワーク接続ファイルシステムへのパスを含むファイルがあることです。ファイルはGit無視されます。

これは2つの理由で不完全な解決策であると感じています。NASが動作していない、遅い、または完全なテストを実行できないほどダウンしている場合。2番目の理由は、誰かが最初にリポジトリのクローンを作成するときにユニットテストが失敗するため、特定の名前で物をマウントする方法と、テストパスファイルの構築に使用される構文を理解する必要があるためです。

だから私の質問は二つあります。どのくらいのデータが多すぎてリビジョン管理に保存できませんか？

大量のテストデータを処理するためのより良い方法は何ですか？

ビルドチェーンで大きなファイルを処理する方法

MavenやGradleなどの依存関係管理を行うビルドツールを使用するのが好きです。ファイルはWebリポジトリに保存され、依存関係が発生すると、ツールが自動的にダウンロードとキャッシュを処理します。また、テストを実行したい人のための余分なセットアップ（NAS構成）も不要になります。また、データの更新がかなり楽になります（バージョン管理されています）。

リビジョン管理に入れるには大きすぎるもの

大きな灰色の領域があります。そして、RCSに属さないものを決定した場合、代替手段は何ですか？RCSとバイナリリポジトリ（mavenスタイル）の間で選択を制限すると、より簡単な決定になります。

理想的には、人道的に編集可能、差分可能、または履歴を追跡したいRCSのものだけが必要です。ビルドやその他の種類の自動化の産物であるものはすべて、そこには属していません。サイズは制約事項ですが、主なものではありません。巨大なソースファイル（悪い習慣）は、間違いなくソース管理に属しています。小さなコンパイルされたバイナリはそうではありません。

開発者の便宜のために妥協する準備をしてください。

NASが動作していない、遅い、または完全なテストを実行できないほどダウンしている場合。

明らかに、これを解決するには、NASから5GBをローカルドライブにコピーする必要があります。しかし、これを手動で行う必要はありません。

2番目の理由は、誰かが最初にリポジトリのクローンを作成するときにユニットテストが失敗するため、特定の名前で物をマウントする方法と、テストパスファイルの構築に使用される構文を理解する必要があるためです。

これを正確に実行する単純なシェルスクリプトを提供できます。特定の名前でNASをマウントし、ローカルドライブにデータがまだない場合や、NASのデータセットがローカルデータセットよりも新しい場合に、データをローカルドライブにコピーします。単体テストの初期化段階でスクリプトが自動的に実行されることを確認してください。

もちろん、これらのデータセットの1つだけでなく、ソースコードリポジトリの外部にある外部ファイルへの依存関係がたくさんある場合は、@ ptyxで言及されているようなツールがより良い解決策になる可能性があります。

...誰かが最初にリポジトリのクローンを作成すると、ユニットテストが失敗するため、特定の名前で物事をマウントする方法と、テストパスファイルの作成に使用する構文を理解する必要があります。

まず、一貫した用語を使用します。この種のテスト（大きな外部依存関係、実際のデータ）は、通常、単体テストではなく、統合テストまたはシステムテストと見なされます。

実際的な注意：単体テストと統合テストを別々にしておくことは良い習慣だと思います。なぜなら、それらは異なる長所と短所を持っているからです。

• コード内の2種類のテストを分離する（命名規則、個別のプロジェクトなど）
• 2つのテストスイートのうち1つだけを実行する方法を提供する
• 通常のビルド中に単体テストのみを実行する
• オンデマンドで、およびCI（継続的インテグレーション）サーバーで統合テストを実行する

このようにして、ローカルビルドは高速で信頼性が高く（外部への依存がほとんど/まったくありません）、統合テストはbeefy CIサーバーによって処理されます。これにより、説明した問題が回避されます。

データを保持する方法について：

1つの適切なオプションは、ptyxの回答で説明されているようなアーティファクト管理の一種です。もう1つは、テストデータを別のリポジトリに配置することです。いずれにせよ、データはメインビルドと一緒にリリースされるわけではありません。別のリポジトリを用意することで、全員がソースコードと共にテストデータを取得する必要がなくなります。つまり、アーティファクト管理として2番目のリポジトリを使用します:-)。