テストデータをバージョン管理にチェックインする必要がありますか？
PDFファイルを処理する機能のテストコードを書いています。テストの背後にある基本的な考え方は、特別に選択したいくつかのPDFにそれらを向け、それらを処理してチェックすることです出力は私が期待するものであること。
私の質問は次のとおりです。これらの大規模なPDFはどこに保存すればよいですか？それらをコードとともにバージョン管理にチェックインする必要がありますか？またはそれらを別の場所に置きますか？明らかに、テストコードはPDFなしでは（または別のPDFでも）役に立たないのですが、それらをリポジトリに配置するのは間違っているように感じます。
バージョン管理システムには、ビルド、コンパイル、test、および配布用アプリケーションのパッケージ化（MSI、RPMなど）に必要なすべてのものが含まれている必要があります。また、ビルド構成と他のスクリプトもバージョン管理にあるべきだと主張します。
プロジェクトをチェックアウトして、完全なコンパイル、ビルド、およびテスト環境を用意できるはずです。
テストデータをチェックインするには、2つの方法があります。まず、テストデータ自体（この場合はPDF）をチェックインできます。次に、テストデータの生成に使用できるソースデータをチェックインできます（該当する場合）。これは、テストデータを含む空のデータベースに読み込まれたSQLスクリプト、またはPDFまたは他のファイルにコンパイルできるテキストベースのファイルです。
他の人がバージョン管理にすべてをチェックすることに同意しないかもしれませんが、私は専門的な経験で、完全な環境をスクラッチ。
準備したセットアップファイルがないとテストが役に立たない場合は、テストコードとともにVCSにファイルを含めるのが理にかなっています。
テストで使用されるファイルはコードではありませんが、コードが依存する依存関係としてそれらを表示できます。したがって、すべてをまとめることにメリットがあります。
対照的に、VCSの中には大きなバイナリファイルをうまく処理できないものもあれば、VCSにあらゆる種類のバイナリファイルを含めることに強い反対をするものもあります。これらのいずれかのケースが当てはまる場合は、簡単にアクセスできるよく知られた場所にテストファイルを保存することも意味があります。
また、「すべてのテストを実行するにはfoo.pdfに依存している」というコメントをテストコードに含めることも検討します。
静的データの場合は、バージョンコントロールに配置します。それらがチェックインされると、これらのファイルは実際には変更されません。その機能が不要になった場合は削除されるか、新しいテストファイルが追加されます。どちらの方法でも、不十分なバイナリdiffが領域を占有することを心配する必要はありません。
もしあなたがgeneratingテストデータなら、例えば。ランダムに、テストが失敗したときに自動的に保存し、それ以外の場合は破棄する必要があります。この方法で保存されたデータはすべて、定期的な回帰テストに変換する必要があります。これにより、これらのEdgeケースは、抽選の幸運に頼るのではなく、将来的に確実にテストされます。
テストとメインアプリケーションコードにそのデータを確実に含めてください。非常によく整理されたテストスイートがあると役立ちます。そのため、PDF抽出をテストしている場合（そのコードが適切にカプセル化されている場合）、アプリのコードへのパスに基づいて、テストデータへのパスを構築できます。 -それは常に私のために働いています。
Gitを使用すると、.gitignoreを設定して、一時的な出力やテストログがリポジトリを汚染するのを防ぐことができます。