如何测试输出/修改文件的模块/脚本？
我有几个模块（DZP::Catalyst 和 DZP::OurPkgVersion) 它们的目的都涉及将文件写入磁盘。我不确定如何测试它们，是否有任何好的策略来测试写入磁盘的文件？我可以去任何地方阅读它吗？
I have a couple of modules (DZP::Catalyst and DZP::OurPkgVersion) both of their purposes involve writing out files to the disk. I'm not sure how to test them, are there any good strategies for testing files written out to disk? any place I could go to read up on it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，在这种特殊情况下（Dist::Zilla 插件），你想要使用 Dist::Zilla::Tester。它负责创建临时目录、向其中填充文件以及事后清理等大部分繁重工作。例如，请参阅 我的 DZP::CJM 的测试< /a> 或 来自 Dist::Zilla 本身的测试，特别是插件目录。
更新： Dist::Zilla 4.200002 引入了 Test::DZil< /a> 模块，它添加了一些对测试插件有用的实用函数。您可能想要使用它而不是直接使用 Dist::Zilla::Tester。
Well, in this particular case (Dist::Zilla plugins), you're going to want to use Dist::Zilla::Tester. It takes care of much of the grunt work of creating a temporary directory, populating it with files, and cleaning up afterwards. For example, see the tests from my DZP::CJM or the tests from Dist::Zilla itself, especially the plugins directory.
Update: Dist::Zilla 4.200002 introduced the Test::DZil module, which adds some utility functions useful for testing plugins. You'll probably want to use it instead of using Dist::Zilla::Tester directly.
这在某种程度上取决于模块，但我的总体策略是：
确保文件内容逻辑与文件机制 100% 分离（就不同方法而言）（例如选择目录/打开文件/关闭文件/错误处理） ）。
确保文件机制 100% 灵活，例如，您可以从外部驱动程序中选择目录/文件名。
为文件机制编写测试，只需打开指定目录中的指定文件，关闭它，确保没有错误发生，并且预期文件存在且大小为零
创建一个测试数据数组，数组的每个元素由 3 部分组成
文件内容逻辑的输入数据，可能与测试配置相结合，指示文件内容逻辑中的哪些方法在必要时调用该数据。
预期要设置的文件名
预期的文件内容，采用 tar 压缩的预期文件的形式（具有要生成的确切预期内容和正确的预期名称的确切文件）。
预期结果 tarball 应该位于测试脚本所在目录下的单独子目录中（例如“expected_results”）。
您需要一个 tarball，以防您的文件生成逻辑生成超过 1 个文件。
然后运行一个循环在您之前创建的测试数组中的每个测试上：
创建一个新的“实际结果”临时目录（或清理之前测试中的临时目录）
将模块中的目录设置为临时目录；将模块的文件名设置为测试信息中预期的文件名。
运行文件打开器方法（之前测试过）
使用测试的逻辑方向（如果适用）和测试的输入数据从模块运行内容生成逻辑。
运行文件关闭方法（之前测试过）
创建一个“临时预期结果”临时目录（或清理上次测试中的临时目录）
将“预期结果”压缩包从“expected_results”测试子目录复制到上一个要点中创建的“临时预期结果”临时目录
在“临时预期结果”临时目录中解压缩该 tarball 并从那里删除 tarball。
directory-diff“临时预期结果”临时目录与“实际结果”临时目录（例如，确保两者具有 100% 相同的文件列表，并且每个文件的内容 100% 相同，无论是通过本机 Perl或通过
system()调用使用diff。因为上面的逻辑非常通用，所以我通常将其大部分抽象为“Test::FileGenerator”模块，由测试文件生成能力的所有单元和集成测试重复使用。
It depends somewhat on the module, but my general strategy is:
Ensure that file content logic is 100% separate - as far as being in different methods - from file mechanics (e.g. choosing directory/opening files/closing files/error handling).
Ensure that the file mechanics is 100% flexible, e.g. you can choose the directory/filename from the external driver.
Write tests for the file mechanics, by simply opening the specified file in specified directory, closing it, making sure no errors happen and that expected file exists and has size zero
create an array of test data, with each element of the array consisting of 3 parts
Input data for file content logic, possibly coupled with test configuration indicating which methods from file content logic to call on that data if warranted.
Expected file name to be set
Expected file contents, in the form of tar-balled expected files (exact files with exact expected content to be generated and the correct expected name).
The expected results tarballs should be in a separate sub-directory (say "expected_results" under the directory where your test script lives.
You need a tarball in case your file generation logic produces >1 file.
Then, run a loop over each test in the test array you previously created:
Create a new "actual results" temp directory (or clean up the one from prior test)
Set the directory in you module to the temp directory; set the filename of your module to the expected filename from test info.
Run the file opener method (previously tested)
Run the content generation logic from the module using test's logic directions (if applicable) and test's input data.
Run the file closer method (previously tested)
Create an "temp expected results" temp directory (or clean up the one from last test)
Copy an "expected results" tarball from "expected_results" test sub-directory to the "temp expected results" temp directory created in last bullet point
untar that tarball in "temp expected results" temp directory and delete the tarball from there.
directory-diff the "temp expected results" temp directory with "actual results" temp directory (e.g. ensure both have 100% identical list of files and that each file's contents are 100% the same, either via native Perl or using
diffviasystem()calls.Since the logic above is very generic, I generally abstract most of it away into a "Test::FileGenerator" module re-used by all of the unit and integration tests that test file generation ability.