如果一个模块A
依赖于模块 B
和模块 B
已升级,A
可能会因更改而中断。我的想法是重新测试A
和 B
升级后B
.
我认为最简单的方法就是重新测试可以重新测试的所有内容:从 CPAN 下载每个已安装的模块并执行其测试脚本。
有没有办法下载和重新测试?
如果没有办法,是否有任何帮助程序/API,以便我可以实现这样的工具?
我基本上需要
最佳答案
cpan
核心 Perl 附带的工具包括 -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
你会得到:“
File::Temp was first released with perl v5.6.1
”如果你这样做:
corelist JSON
你会得到:“
JSON was not in CORE (or so I think)
”因此,确定您在列表中查看的模块是否是 Perl 附带的模块非常简单。使用您认为合适的信息。
您必须解决的另一件事是如何处理共享依赖项。如果您测试的第一件事是 Moose 升级,那么您将占用一半的 CPAN(这是夸大其词),这会弄脏您测试其他模块的环境。为了减轻这种影响,您有几个选择。一是利用
App::perlbrew
及其lib
设置一次性图书馆空间的选项。这样你就可以在 perlbrew lib
指定的目的地安装一个模块和它的依赖。和 perlbrew use
,然后在完成后将其丢弃以继续进行下一个库进行测试。但是,可能有一个更好的解决方案,我对这里的文档不太熟悉:CPAN 冒烟测试人员使用的工具链。见 CPAN::Testers如果你想追求这个策略。冒烟测试人员已经制定了相对轻量级的方法来以自动化的方式下拉和测试模块及其依赖项。
最后,您将遇到的另一个问题是 CPAN 作者决定哪些版本的模块存在于 CPAN 上,哪些版本会被删除。几年前,CPAN 作者被鼓励通过删除旧版本来保持其 CPAN 存储库的清洁。我不知道是否仍然鼓励这种做法,但这确实意味着您不能指望仍然存在的特定版本号。为了解决这个问题,您可能应该为您在给定时刻安装的所有版本维护自己的 tarball 存储库。 CPAN 模块框架Pinto有助于保持模块的版本,固定一些不更新,以及其他有用的技巧。
关于perl - 我可以重新测试所有已安装的 CPAN 模块吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49349731/