維持する必要のある(大きな)テストファイルがいくつかあります。これは、彼らの歴史へのアクセスが要件であることを意味します。
メリット
git pull
。欠点
テストファイルを維持するためのベストプラクティスは何ですか?
これらのファイルをソース管理に保存しますか?代替案はありますか?
それらをソース管理に保管します。あなたが挙げた利点はすべて非常に良いものです。これを行うと「巨大な」サイズになるとあなたが言ったとき、あなたはどれだけ巨大な話をしていますか?数百ギガバイト?テラバイト?
ストレージが実際にそれほど問題である場合は、ファイルを圧縮し、Zipファイルをソース管理に保存し、テストケースの実行時にそれらを解凍するスクリプトを作成できますか? (ファイルを解凍してメモリに履歴を表示するツールを見つけられない限り)その方法で各ファイルの詳細な履歴は失われますが、新しい開発者はテストファイルに簡単にアクセスできます。
テストデータの性質に応じて、テストファイルを生成するスクリプトを作成できます。これは、手続き的に生成できる非常に大きな画像をテストする場合に機能する可能性があります(データベースにデータを挿入するSQL挿入は、プログラムまたはスクリプトによって簡単に生成することもできます)。ただし、この手法はすべての種類のテストデータに適用できるわけではありません...
ソース管理に保存します。コードなしのテストスイートが必要になるケースはありますか?意味がありません。テストスイートを更新せずにコードを編集したい場合はありますか?あってはいけません。
最近のストレージの価格を考えると、欠点1は問題にならないはずです。また、最近のSCMシステムでは、初期設定以外のネットワークアクティビティも問題にならないはずです。
あなたの欠点2は、多くあるべきではないようです。このプロジェクトに新規開発者が参加する頻度はどれくらいですか。最初のクローン時間が問題になります。
別のリポジトリに保存します。かさばるテストスイートがある場合、あなたが言及した欠点は避けられません。