Question

如果模块A依赖于模块B并且模块B已升级，则A可能会因更改而中断。我的想法是在升级A后重新测试B和B。

我认为最简单的方法就是重新测试可以重新测试的所有内容：从CPAN下载每个已安装的模块并执行其测试脚本。

有下载和重新测试的方法吗？

如果没有办法，是否有任何助手/ API，以便我可以实施这样的工具？

我基本上需要

查询安装的内容（包括版本号）
下载并解压缩确切版本
执行测试

Answer 1

核心Perl附带的cpan工具包含-l选项，指示它提供已安装模块的列表。例如，我系统列表中的最后10项：

$ cpan -l 2>/dev/null |tail -10
Test2::Event::Encoding  1.302073
Test2::Event::Bail  1.302073
Test2::Event::Exception 1.302073
Test2::Event::Subtest   1.302073
Test2::Event::Skip  1.302073
Test2::Event::Info  1.302073
Test2::Event::Diag  1.302073
Test2::Event::TAP::Version  1.302073
JSON::PP    2.27400_02
JSON::PP::Boolean   undef

如此处所示，您将获得模块和版本号的列表。有时，该工具无法在META中找到该版本，因此将返回undef版本号。 CPAN作者应该注意这些类型的错误，因为它们使得希望识别版本而不编译模块本身的工具更难。

获得模块和版本号后，您可以使用cpanm工具（由App :: cpanm提供）及其--test-only选项来下载特定版本的模块并对其进行测试。您可以申请这样的特定版本：

cpanm Some::Module@0.9990

（仅下拉目标模块的0.9990版本。）

事情变得棘手的是：Perl附带了一堆模块，其中一些还通过CPAN接收更新。 cpan -l工具将列出所有已安装的模块，包括Perl附带的模块。

此外，列出的某些模块只是更大分布的一部分。

另一个对你有用的工具是corelist，它自5.8.9以来就与Perl捆绑在一起。如果你运行这个：

corelist File::Temp

您将获得：＆＃34; File::Temp was first released with perl v5.6.1＆＃34;

如果你这样做：

corelist JSON

您将获得：＆＃34; JSON was not in CORE (or so I think)＆＃34;

因此，确定列表中您正在查看的模块是否与Perl一起提供的模块非常简单。根据需要使用该信息。

您必须解决的另一件事是如何处理共享依赖项。如果您测试的第一件事是Moose升级，那么您将提取一半CPAN（这是夸大其词），这将污染您的环境以测试其他模块。为了减轻这种影响，您有几个选择。一种是利用App::perlbrew及其lib选项来设置一次性库空间。这样，您可以在perlbrew lib和perlbrew use指定的目标中安装模块及其依赖项，然后在完成后将其丢弃以转移到下一个库进行测试。

然而，可能有一个更好的解决方案，我不熟悉这里的文件：CPAN烟雾测试仪使用的工具链。如果您希望采用此策略，请参阅CPAN::Testers。烟雾测试人员已经制定了相对轻量级的方法，以自动化的方式下拉和测试模块及其依赖性。

最后，您将遇到的另一个问题是CPAN作者决定哪些版本的模块在CPAN上运行以及哪些版本被删除。几年前，CPAN的作者被鼓励通过删除旧版本来保持他们的CPAN存储库清洁。我不知道这种做法是否仍然受到鼓励，但这确实意味着您不能指望仍然存在的特定版本号。要解决此问题，您应该为您在给定时刻安装的所有版本维护自己的tar包存储库。 CPAN模块框架Pinto有助于保留模块的版本，固定一些不更新，以及其他有用的技巧。

Answer 2

如果您将分发B和cd下载并解压缩到该目录中，则可以使用brewbuild中的Test::BrewBuild二进制文件（注意：需要Perlbrew或Berrybrew）用于测试-R的{{1}}又名--revdep标记以及需要B的所有发布：

每次我更新一个具有反向依赖关系的CPAN发行版时，我都会这样做，因此我不会破坏我的dists的任何消费者。

我可以重新测试所有已安装的CPAN模块吗？

2 个答案: