如何从hg repo中安装的库中隔离出来进行测试?

时间:2015-12-30 14:33:41

标签: perl

如何使用本地hg repo库来测试已安装的libs的隔离?

已安装的生产perl包和本地hg repo具有相同的结构

    +-- lib
        |-- modA.pm
        |-- modB.pm
    +-- bin
        |-- example.pl
    +-- t
        |-- modA.t
        |-- modB.t

安装在库中,并将路径添加到@ PERL5

/nfs_share/perl/
env|grep -i perl
PERL5:/usr/local/perl:/nfs_share/perl

local hg repo at:

/data/user/hg/perl

modB.pm

#!/usr/bin/perl
use modA;
sub modB_compare{
    my (x,y) = @_;
    # .....
    return x-y;
}

仓/ example.pl

use FindBin qw($Bin);
use lib "${Bin}/lib/";
use modA, modB;
# if this call is from local lib
my $result = modB_compare(x,y);
# if sub being called from production or local hg?
my $result2 = modA_method();
# from local hg repo or from production lib?!

如果我要在本地hg repo中修改和测试,我没有保证我调用的lib来自本地仓库,而不是来自生产库。

在本地hg repo中测试库的潜在解决方案是什么?

2 个答案:

答案 0 :(得分:3)

简短回答:对于测试,只需使用prove -l

  

如果我要在本地hg repo中修改和测试,我没有保证我调用的lib来自本地仓库,而不是来自生产库。

实际上,对于您定义的问题存在

如果您知道./lib/modA.pm中存在./lib/@INC中存在./lib/modA.pm,则会加载use lib并且任何系统perl版本都不会*。

您的use lib语句会按照perlvar @INCrequire中的说明为您执行此操作。

但是,对于测试,perl -Ilib t/modA.t通常,而 使用-I flag in perl-l)或,更好,prove,它也有一个prove -l标志,因此您可以t/使用./lib中的模块运行use中的所有测试}。

注意:您可能还想查看有助于分发任务的ExtUtils::MakeMakerModule::Build::Tiny,您可能需要考虑Dist::Zilla或(为了更快开始){{3 }}

如果您只是想验证发生了什么您可以通过查看Dist::Milla来查看requirelocal::lib语句中已加载的文件。

如果您绝对必须控制哪些模块可以访问,例如,因为您要根据是否安装了第三方模块(而不是您自己的代码)来测试不同的行为,我建议您进入%INC。这将帮助您编译自己的perl(几乎任何模糊的近期版本),它不使用系统perl中的库,而是使用lib创建自己的库;然后,您可以在多个已安装的perls之间切换。唯一的例外是与perl本身打包在一起的库;您可以从perlbrew获取这些列表。

最后,您可能想查看Module::Corelist。我不认为这是你所要求的,但它是一个类似的问题领域,我认为值得一提。

*确定,严格来说,@INC必须出现在系统perl lib目录之前的lib 中,因为会发生的事情是perl通过@INC 命令并找到与您要求加载的包名相对应的文件;您在本答案中使用的所有方法都将确保您的@INC目录早于net.IP出现在系统perl libs中。

答案 1 :(得分:2)

这可能是一些蠕虫病毒 - 因为每当你尝试维护并发的“已安装”版本时,你就可以很容易地绊倒不正确的依赖项。这是可行的,但在制作开关时你必须特别小心,不要误用“错误”版本。

结果 - 对于这种情况,我正在使用Docker。有可能简化一点,这是一种将应用程序实例与其依赖关系打包成一种迷你虚拟机的方法。

您可以从docker文件创建一个图像,它与make文件非常相似,只是它“构建”到一个图像中,然后您可以运行它 - 包括您的应用程序及其所有依赖项。

我也在我的生产实例中使用Docker容器,我感谢您在您的环境中可能不是一个可行的答案。但我这样做的重点是,我可以发展到我心中的内容,然后当我准备好发布时,建立一个新的“参考”图像以交给测试。

如果该参考图像通过,那么完全相同的图像将被部署到prod中。因为它是自包含的,并且包含了所有它的依赖项,所以我非常自信我不会因为安装的库的版本偏差而绊倒,也不会因为未来的更新而破坏任何东西 - 因为我的一切都是'版本'需要运行是图像的一部分。

但结果是,你的环境非常干净,几乎不用担心你担心的事情。

你甚至可以相当安全地在相同的物理锡上运行你的dev / ref / prod,然后绑定/映射不同的资源(卷/端口等)来区分。