[软件工程]XP是否必须全套自动化测试呢?

今天看到张恂先生文中对XP应用自动化测试提出了他的看法:

—— 前面提到“采用 XP 框架的”占 43%,而用自动化测试工具的只有 30%,那么请问,这中间的 13% 算什么?会用 XP,却不会用自动化测试工具(如 xUnit)?显然这次调查的样本是有问题的,调查的组织和问题设置好像也存在缺陷。关于我的这段评论,青润回应道:


关于用 XP 是否会用自动化测试工具,我认为这不是必然的联系,会用与否,使用 XP 中的那些关键实践,这都是一家公司/团队可以选择的,任何一家公司/团队都可以根据自己的特点或者项目特点选择在某个阶段采用某种过程或者开发方法来进行,而在另一个阶段有计划的选择另外一种过程或者开发方法。会用与是否全部采用之间是有差别的,所以,我不认为这两个数据间相差的 13% 有什么严重的过错。

XP 团队不用自动化测试工具?您在说胡话吧,发烧 40 摄氏度?在 XP 的开发循环中,每次您做完了代码重构,舍弃 xUnit、TestNG 这样众多的自动化测试工具,进行手工测试?手工测试对于系统/验收测试还可行,请问对于大量的单元测试,您到底怎么个手工测试法?究竟是什么原因使得您非要舍近求远,舍简就繁?为了要誓死捍卫你那老哥的“43% 的企业采用了 XP”的极端正确性?太累了吧,我觉得您在强辞夺理。结论是,采用 XP 的团队必然要使用自动测试工具,不管是单元测试、集成测试,还是系统测试,而且应该大量使用。

青润说的“任何一家公司/团队都可以根据自己的特点或者项目特点选择在某个阶段采用某种过程或者开发方法来进行,而在另一个阶段有计划的选择另外一种过程或者开发方法”,这句话没错,但这只是原则上的情况。

对于 XP,需要具体情况具体分析。我们可以把所有的 XP 做法,分为两大类:核心的、必需的做法(core practices),以及可选的做法(alternative practices)。如果你抛弃了 XP 的核心做法,那么你的过程就不能叫 XP 了。采用自动化测试工具就是这样一项核心做法,这点我们可以依据逻辑分析从其他的 XP 核心做法推导出来。青润所说的“会用与否,使用 XP 中的哪些关键实践,这都是一家公司/团队可以选择的”,是不对的,实际情况是,有些可以,有些不可以。我们区分 XP 与其他过程,看一个过程是不是 XP,关键就是看人们是否做到了这些“关键实践”,以及它们是否符合 XP 的原则和精神。XP 的 X 是 Extreme 的意思,意味着很多地方应该严格要求(high-disciplined),尽可能做到极致,如果关键核心实践可用可不用,那不是 XP,是 MP(Mild Programming)。人们很难想象,不采用自动化测试工具,XP 怎么能够进行下去,怎么能够保证敏捷性。

” 

上面为直接引用过来未经任何修改的文字。

这篇文字中,让我感到一个异常情况,那就是:张恂先生学习的东西是否太过照本宣科了,按照开国主席毛先生的话来说,那就是:本本主义!

我个人对XP的了解并不是很多,不敢称这方面的专家,测试方面我了解得也不多,但是,在这两个方面多少都看过一些东西,也不至于一无所知。

但是,为了考虑到权威性和准确性,这方面的问题我想请测试时代的贺忻老哥来做下解释,这两天我就会和他联系,看他的时间了。

另外,需要声明:

张先生文中说我维护我的老哥!

张先生指的肯定是熊节,张和熊节之间的恩怨我多少有些了解,不过,在这里,我认为这是一个很奇怪的称呼,我从来没有认为熊节是我老哥,熊节的年龄要比我小,怎么成为我老哥了?张先生这样给我戴帽子,是不是给人一种有点辖私报复的感觉呢?

——这种图呈口舌之力,而没有任何实据就随意猜测的行为和文字在张恂先生的文章中还有多少?这似乎是我们值得深思的一个问题了!

另外,我认为无论是RUP/UP或者XP,他们如果都是必须整体使用才能算作是他们自己这个概念的话,那么RUP/UP的裁剪是不是也成了一句空话呢?

我的经验认为:

只要是适用于我解决项目中实际问题的方法,无论他们是属于RUP/UP还是属于XP,我都会拿出来使用,而不会因为我采用了RUP/UP的框架,而拒绝XP中的一些方法建议。这才是软件工程的实质,而不是一种抽象空洞的理论!

RUP/UP和XP中的任何一个部分都可以拆解出来根据需要使用,只要使用了其中任何一个部分,我们也都不能否认我们采用了或者借鉴了RUP/UP或者XP,很多人也会认为他们使用了RUP/UP或者XP,而不会认真追究是否全部采用了RUP/UP或者XP。

而在张恂先生的这段文字中,本本主义的固执与观点表现得十分强烈,并且明显。

我很难相信,在这样固执的观点和思维下,张恂先生是如何给自己的客户提供服务的,如何帮助客户解决实际问题的。这样的固执思维,也许会把用户本来可以快速解决的问题扩大化(就像文化大革命),给客户带来很多不必要的损失和浪费。

张恂先生的思维和做法明显不是一个从底层做起的程序员正常的思维,也许张先生没有这样的底层程序员的工作经验的缘故(在他的简历中我没有看到过相关的内容),所以,他不能理解我们这些从最低层做起的程序员的想法和考虑。

软件工程是为了实用,是为了解决实际问题,而不是为了夸夸其谈,更不是为了照本宣科,标榜自己如何的专业与高深,攻击他人而宣传自己的地位与影响,夸张自己的做法而贬低他人。解决问题,才是软件工程之本,而不是断章取义,本本主义!

切切以为此语,盼张先生反思一二。

你可能感兴趣的:(全程建模)