是否应该将测试数据检查到版本控制中？

我正在为处理PDF文件的功能编写一些测试代码。测试背后的基本思想是，将它们指向我专门选择的一些PDF，它们会对其进行处理，然后检查输出是否符合我的期望。

我的问题是：我应该在哪里存储这些大尺寸的PDF？我应该将它们与代码一起检查到版本控制中吗？还是将它们放在其他地方？显然，没有PDF（甚至不同的PDF）的测试代码是没有用的，但是仍然将它们放入我们的存储库中仍然感觉不对。

您的版本控制系统应包含构建，编译，测试和打包要分发的应用程序所需的所有内容（例如MSI，RPM）。我也认为构建配置和其他脚本也应该在版本控制中。

我应该能够签出一个项目，并具有完整的编译，构建和测试环境。

有两种方法可以检入测试数据。首先，您可以检入测试数据本身（在这种情况下为PDF）。其次，您可以检入可用于生成测试数据的源数据（如果适用）。这可以是加载到包含测试数据的空白数据库中的SQL脚本，也可以是可以编译为PDF或其他文件的基于文本的文件。

其他人可能会不同意将所有内容都检查到版本控制中，但是根据我的专业经验，我发现确保能够从头开始重建完整的环境至关重要。

如果没有准备好的安装文件，测试无用，则可以将文件和测试代码一起包括在VCS中。

虽然测试中使用的文件不是代码，但是您可以将它们视为代码所依赖的依赖项。因此，将所有内容保持在一起是有好处的。

作为对策，某些VCS不能很好地处理大型二进制文件，而其他VCS强烈反对在VCS中包括任何类型的二进制文件。如果您遇到这两种情况中的任何一种，那么将测试文件存储在易于访问的众所周知的位置也很有意义。

我还将考虑在测试代码中添加一条注释，指出“ foo.pdf运行所有测试所依赖”。

如果是静态数据，则将其放入版本控制中。这些文件一旦签入，就不会真正更改。如果不再需要该功能，它们将被删除，或者将在其中添加新的测试文件。无论哪种方式，您都不必担心差的二进制差异占用空间。

如果您正在生成测试数据，例如。随机，那么您应该在测试失败时自动保存它，否则将其丢弃。以这种方式保存的任何数据都应转为常规回归测试，以便将来肯定会测试那些极端情况，而不是依靠抽签的运气。

绝对在测试和主要应用程序代码中包含该数据。拥有一个井井有条的测试套件会很有帮助-因此，如果您正在测试pdf提取（并且您的代码已被很好地封装），那么您应该能够根据应用程序代码的路径来构建测试数据的路径-一直对我有用。

使用git可以设置.gitignore，以防止任何临时输出或测试日志污染您的存储库。