Phalanx 项目

最新推荐文章于 2025-09-08 18:49:10 发布

原创最新推荐文章于 2025-09-08 18:49:10 发布 · 1k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#测试 #perl #工作 #subversion #文档 #版本控制系统

本文围绕Phalanx项目展开，该项目以Perl为基础，利用自动化测试机制保障Ponie仍是真正的Perl 5。项目选取CPAN中下载最多的前100个模块进行测试，目标是找出程序bug、完善文档，还为人们提供参与开源和学习自动化测试的平台，并介绍了相关工具和加入方式。

Phalanx 项目

翻  译：盛春
出  处：中国Perl协会 FPC(Foundation of Perlchina)
原  名：The Phalanx Project
作  者：Andy Lester
原  文：http://www.perl.com/pub/a/2005/01/13/phalanx.html
发  表：2005-01-13
Perlchina提醒您：请保护作者的著作权,维护作者劳动的结晶。

Phalanx 是一个旨在完善 Perl 模块自动化测试，提高模块质量的开源协作项目。作者介绍了该项目的来由，目标，工作形态及其进展，同时还鼓舞人们加入该项目。

Phalanx 项目

让我们先想象一个由为数不多的士兵保护着的城池，这个城池未来的发展需要更为强大的军事力量，于是少数信念坚定的陆军中尉赶到邻城，从他们中间募集更多的志愿者，以便在将来城池变得越来越壮大的时候能够提供强大而有力得辅佐。

这就是 Phalanx 项目，而这个城池就是 Perl，我们的士兵就是那些自动化的测试机制，邻城就是 CPAN 里面众多的模块。

话说 2003 年的 OSCON 大会。Larry Wall 在他的第七次 Onion 状况例行报告中宣告了 Ponie 项目。Ponie 将要成为 Perl 5.10 ，但它会运行在 Parrot 虚拟机（集成了 Perl 6 的基本概念，而不是 C 的虚拟机）上。

我曾经和 Leon Brocard 聊起过，大量的测试对于 Perl 新版本的开发非常重要，不可或缺。所有我们知道的，或者我们设想的东西都可能会发生变化。那么我们又怎么能知道每次总能够得到 2+2=4 的正确结果呢？我们又如何能知晓对象继承在起作用？XS 模块正在按照既定的方式工作吗？我们该要有个非常巨大的，远超过目前 Perl 所有的测试集合，来保证 Ponie 仍然是真正的 Perl 5 。而 CPAN 则自然而然的成为现实世界中测试工作的最为庞大和丰富的资源。

有哪些模块呢？

我没有想过要让 Phonie 覆盖所有的 CPAN 模块，我只是想要遵循 Pareto 原则，只覆盖最前面的 10% 的那些。然而，在 Phalanx 开始启动的时候 CPAN 里面就有 4,000 左右的模块（而现在这个数字大约是 6,000）了，400 个模块的工作量仍然非常巨大，于是，我选择了一个更为实际的数字：100 ，大约 2.5% 的模块发布量。

那么如何取舍最前面的那 100 个模块呢？理想地，我想知道哪些模块在现实生活中最为常用就取其中的前 100 个，不过这似乎不太现实。而模块的下载次数在一定程度上体现了这种概念。（一些有洞察力的读者可能已经想到了这种解决办法存在的问题，但请放松，因为我也早已仔细考虑过这些问题了。）

Phalanx 最前 100 个模块就是那些在最近的 45 天内，从各大 CPAN 镜像站点下载最多的那些模块。我们对统计数据作了些调整，去除了出现在各个镜像站点上搜索引擎爬虫的访问纪录，和其他可以断定是对CPAN做镜像的下载行为，同时我也判定在 45 天内下载超过 450 个模块的固定 IP 地址为机器人程序，同样的去除它们的下载纪录。

为什么称作为“Phalanx”？

在古希腊，phalanx 是众多士兵排成方阵形成护盾的一种军用编队名称，每个人都肩并肩排列，他们的盾牌重叠着相接。当 phalanx 中的每个人都拥有着护盾时，就好比 Phalanx 项目中形成的为数众多的，交错排列的测试代码。

对于任何一套程序，你拥有越多的测试代码，你就拥有越多的保护。如果你能够写点测试的东西，你就该去做这些工作。看看这里的一些简单的测试和一个项目对象的构造器及访问存取器（使用 Perl 的测试框架进行的测试）：

my $project = Project->new( name => "Phalanx" );
isa_ok( $project, "Project" );
is( $project->name, "Phalanx", "Name set correctly" );

有人可能会说，“这不过是个存取器，为什么我非要去测试它？”如果这段代码在实际的生产应用中无法正常工作，你就无从知晓错误产生在哪个处理环节上，所以这种测试仍然是有意义的，是值得的。如果没有测试，那么某些使用 Project::name 存取器的代码就会发生错误，你就可能会花上数小时来追查排摸错误发生的根源，直到回溯到这个有问题的存取器。

这种逼近测试方法（大量的，基于其他测试结果的测试过程），即为 phalanx 中的基本思想，同时也将是 Perl 自己测试框架的基本思想。

目标

Phalanx 项目的主要目标是提高既定若干模块的测试包的质量，大多是通过提高测试所覆盖的模块代码的数量来实现的。当然还有一个次要目标，因为我们自己的工作也离不开这些代码。

第一个小的目标就是要找出隐藏的程序 bug 。当我们为模块增加测试代码的时候，我们希望可以揭开有瑕疵的功能。确实，HTML::TreeBuilder 的工作组在添加了测试后发现了模块中的一个 bug 。

除了添加测试代码之外，工作组的成员还要检查模块文档的完整性和正确性，并填补所有的欠缺。比较代码和内嵌的说明文档注释等，可能会发现一些隐藏的功能特点，这些原来只有读取模块源代码的人才能了解的东西。如此才算完成文档编写过程和自动测试过程。

这里的原则：代码，测试和文档都必须全部保持一致。如果代码作了某件事情，文档也能够正确描述这种功能，而测试代码却检查了另外一种不同的行为，那么这就是一个 bug 。甚至于也可能发生其中两者保持着一致错误的情况，或者三者全部不一致。有时候，一些久远的代码就是这种样子的。

其他两个小目标是关于人的。 Phalanx 为人们提供了一种涉足开放源代码过程的便捷方式。Phalanx 的非常天性的特点就是相互协作，每个团队工作于某个模块，并提交补丁以便其他团队审阅和批准。模块的作者仍然控制着全局，只是和这些工作组协同工作以决定测试过程应该朝那个方向开展。

其次，Phalanx 为那些对自动化测试感兴趣却又茫然无处下手的人们提供了开始工作的平台。像 chromatic 的 Perl testing kata 系列文章中阐述的那样，把测试代码加入现存的代码中，着实能训练提高工作组成员的技能。

让人们都来注册

在我创建了 Phalanx 100 及指导原则，并安置到 Phalanx 网站后，我必须找些重装备步兵（也就是组成方阵的那些古希腊士兵）。我宣告项目成立后，立即就有一打志愿者加入。每个志愿者把自己的意图写信给模块作者，以便与我们达成共识。否则，创建并提交补丁给一个不愿意接纳的测试代码的模块作者，是一件毫无意义的事情。作者自己可能同时也会提出若干想法和建议，诸如何处需要更多的测试和关注。准备工作结束后，志愿兵便着手开始测试和检查校验文档。

这个过程开始往令人沮丧的失败转变。

十二个不同的志愿兵取纳了 12 个模块发布并在第一年内什么测试代码都没有创造出来。我并不是要在这里说谁是谁非，因为我就是 12 个人中的一个。似乎像这样的项目中，单独工作就意味着难以持续的驱动力。每个我聊过的志愿者都说，一开始信心满满，但后来却发现缺乏时间来持续这些工作，慢慢的，就没什么驱动力了，项目的工作也就弃置一旁了。

今年，我尝试采用另一种从 Perl Mongers 用户组中募集人力的方法，从我自己的，Chicago.com 组开始。接着我有在各种会议上巡回一圈，并在 YAPC::NA 以及 OSCON 上作了简单的报告，请求有兴趣这方面工作的人加入我们的团队。从那以后，SouthFlorida.pm ，London.pm ，和 Perl Seminar New York 都来加入我们的工作，我们仍然与模块作者保持一致，并在我们的中心 Phalanx wiki 站点汇报当前的工作进度，不过现在我希望这可以成组运作，以便更加容易的互动。

Phalanx Tools Phalanx 工具

随着时间的推移，在我们努力构建 Phalanx 项目的基础的时候，我们手上的三种工具充分体现了它们对相互协作所起到的举足轻重的作用。

首先是三元组：电子邮件，web 和 wiki 站点，它们使得人们随着工作进度不断交换信息。建立在 lists.perl.org 主机上的 perl-qa 邮件列表正在为那些致力于测试项目的人们提供服务。Phalanx 网站则公布一些所有的志愿者都看得到的一般信息。而 Phalanx wiki 站点则成了志愿者和工作组公布项目进度的便捷场所。

第二，集中化的版本控制系统也是至关重要的。因为我们有为数众多的合作者在每个独立的模块上工作。幸运的是，perl.org 的 Robert 和 Ask 非常友善地为 Phalanx 团队提供了 Subversion 代码仓库的服务。

第三，Paul Johnson 写的，非常棒的 Devel::Cover 模块成为我们识别测试集合的错误的一个无价之宝。Devel::Cover 分析运行中的测试代码，并鉴别出哪些模块代码行已被测试集合取出来测试过，并提示那些没有测试过的代码行，如此志愿者便可以有针对性地编写相关的测试代码。

Devel::Cover 非常优雅的给出了精确的覆盖程度报告，不过 Phalanx 并不需要百分之一百的覆盖。我们已经发现，在一些案例中，当追求细致到一种极端的程度时，所得到的收益是微乎其微的，特别是那些依赖于特定操作平台的情况。找出较大的被忽略的地方并打上测试补丁才是有实际价值的。这样做的话，可能会有些大的收获，比如我上次发现了 WWW::Mechanize 中没有用的，但也没有去除的代码。