写点什么

Kent Beck 建议超短项目跳过测试

  • 2009-06-23
  • 本文字数:1948 字

    阅读完需:约 6 分钟

Kent Beck 《解析极限编程》《测试驱动开发》的作者,他认为软件开发就如同高尔夫一样,是一项长期和短期相结合的运动。JUnit 是适合于长期运动项目的例子——大量的用户,稳定的收入(如果收入不幸是分文无有的话,对所有参与者都是可悲的),其关键目标是要保证开发领先于使用者的需要。

当我开始实现 JUnit Max 时,才逐渐明白规则已经发生了变化。最要命的问题曾经是(现在也是):“哪些功能可以吸引付费客户?”从定义来看,这是一个无解的问题。如果 JUnit(或任何其他免费软件)实现了一个同样的功能,没有人会为 Max 付费。

JUnit Max 的成功之处在于它开始赢利并不断扩大收入:付费用户越来越多,每个用户所带来的收入越来越多,病毒传播系数【译者注】也越来越高。从定义来看,既然取得成功的方式不为人知,那就进行大量实验,并结合实际使用得到的反馈,这就可以使得成功的机率最大化。

JUnit Max 将所有内部错误报告到一台中央服务器,一旦问题出现,Kent 就立即可以获悉。这种错误日志可以帮助找出两个问题。对于第一个问题,他可以写一个简单的测试使之重现,并验证相应的修补程序。第二个问题解决起来很容易,但 Kent 预计需要几个小时才能为它写出一个测试。在这样的情况下,他就直接修复问题并交付了。

Kent 接着说:

当我开始实现 Max 时,在第一个月里没有做任何自动化测试,所有的测试都是我手动做的。有了最初几个付费用户后,我才回头为已有的功能写测试。并且,我认为这种工作次序让我在单位时间内可以验证的实验数量最多。只用少许或根本不写代码、不写测试,这让我可以更快地开始(我花了近一周的时间才写完第一个测试)。一旦前面的代码被证明是有价值的(就这个项目来说,我的一些朋友愿意为它付费),这种测试就能让我能更有信心地快速完成实验。

是否进行自动化测试,需要对一系列因素进行权衡。即使在 Max 项目中我也写了不少的测试。如果我能找到一种简单的方式写测试,我就会先为所有功能开发验收测试。尤其是在我不能确定某个功能该如何实现时,写测试会给我很好的想法。在 Max 项目中,是否写测试这个问题发生了变化,变成了测试能否有助于我在单位时间内验证更多实验。如果有帮助,那我就写测试。如果没有就不写,甭管有啥危险。我正在力图通过 Max 获得更多收入。要论证围绕设计所付出的努力,这个过程同样复杂,只不过那是下一篇文章要讨论的话题了。

Ron Jeffries 是《极限编程实施》的作者,他回应说:“我相信你,此外还包括三个人,你们能在短期项目中做出正确决策。多年来的经验告诉我:在针对短期项目的决策影响曲线中有一个拐点,项目的可靠性和开发进度会从该点急剧下降。

Johannes Link 是敏捷软件教练 ,他说: “我看到有那么几个开发人员能够作出合理的短期或长期决定,但还没见到过能做到这一点的团队,更不用说一个组织了。”

Michael O’Brien 则给出了不同的评论:“在我看来,这是出色的文章,他也作出了正确的决定。我们在写代码时常常陷于追求漂亮和一致,而忘记了写代码的目的 。我写测试,是因为这可以让我写起代码来更容易,而且让我确信代码按我预想的方式工作。如果写测试不能帮我达到上面的目的,我会说:跳过它。”

Olof Bjarnason 认为:“Kent 提出了反馈流的概念。如果我们着眼于让单位时间内的反馈流多起来,那就走对方向了。例如,他提到在JUnitMax 这个短期项目中,他发布的功能都没有经过测试,这样在项目一开始就可以带来最多反馈流,其原因在于编写第一个测试太困难了,竟用了他一个多星期时间。他通过频繁地修改和发布获得了很高的反馈流。他的‘红色测试’是由早期的少数用户和他们的反馈意见构成。”

Guilherme Chapiewski 有这样的顾虑:在很多情况下人们会误认为某些项目是短期项目。Guilherme 遇到的情况是:之前为了验证某个想法,他打算开发一个没有任何测试的小项目。项目完成后人们开始使用它,很快就找到一些无法修复的 bug。最后,他得出结论: 代码写得太烂,根本无法测试。他只得扔掉已有代码,再从头来过。

Kent 对许多评论做出了回复:“我同意,实践和原则的混乱会导致问题。测试会产生更好的设计。这就是为什么我有大概 30 个功能测试和 25 个单元测试(奇怪的平衡吧,这是由于 Eclipse 应用很难进行测试)。几乎所有的新功能我都先加了验收测试。这样做减少了整个周期耗费的时间。”

这个想法能安全应用到不止一、两个人的团队中吗?除了 Kent Beck,人们是否有能力去判断该不该采用这种方式呢?

译者注:病毒传播系数,英文名为 viral coefficient,用来度量每个已有用户带来的新用户数,与“病毒营销(viral marketing)”相关。可参考: http://robert.zubek.net/blog/2008/01/30/viral-coefficient-calculation/

查看英文原文: Kent Beck Suggests Skipping Testing for Very Short Term Projects

2009-06-23 04:421765
用户头像

发布了 90 篇内容, 共 14.2 次阅读, 收获喜欢 11 次。

关注

评论

发布
暂无评论
发现更多内容

实时数仓实战

鲸品堂

数据 实时数仓

Notebook在复现数据科学研究成果中的丝滑使用

Baihai IDP

AI notebook 数据科学 科研成果

Lazada的算法本土化实践:让东南亚没有难投放的广告

科技新知

一文读懂当今AI圈大热的“MLOps”

澳鹏Appen

人工智能 机器学习 大数据 数据标注 运维开发

看完就会,从抓包到接口测试的全过程解析

伤心的辣条

程序员 自动化测试 接口测试 测试开发 Python自动化

OSPO如何帮助保护你的软件供应链

安势信息

开源 DevOps 开源社区 SCA opensource

工业互联网生态建设加速,小程序容器技术跨端开发特性助力突围

Speedoooo

跨端开发 软件安全 降本增效 敏捷迭代 多端运行

ConcurrentHashMap 源码分析-扩容

zarmnosaj

6月月更

华为云Stack首席架构师:打造“称手”的数字化工具,答好政企IT数字化转型这道必选题

华为云开发者联盟

云计算 数字化转型 多云管理 华为云Stack

测试员该知道的软件测试流程,你都知道吗?

伤心的辣条

Python 程序员 软件测试 IT 自动化测试

想学好软件测试,这些软件必不可少

伤心的辣条

Python 程序员 程序人生 软件测试 自动化测试

Executor

急需上岸的小谢

6月月更

gRPC C++开发环境搭建

赖猫

c c++ gRPC

力扣每日一练之二分查找Day7

京与旧铺

后端 6月月更

博云《应用上容器指南》首发!详解应用容器化改造

BoCloud博云

容器 云原生 容器云 应用

三星堆重大发现!信息量巨大

Dylan

三星堆 四川省 文物

剑指offer系列——剑指 Offer 49. 丑数

未见花闻

6月月更

用FinClip实现App小程序微信授权登录详解

Geek_99967b

小程序 小程序容器

直播回顾 | 传统应用进行容器化改造,如何既快又稳?

BoCloud博云

云原生 容器云 应用

俄航天局局长:外星生命或正在研究人类文明

Dylan

俄罗斯 外星人 航天局

想秀你就秀!环信MVP招募计划正式启动,诚邀您加入!

环信

IT 即时通讯 IM 技术分享

剑指 Offer 58 - II. 左旋转字符串

未见花闻

6月月更

投稿开奖丨云服务器ECS征文活动(3月)大奖公布

阿里云弹性计算

DNS 云服务器 ECS DoH

如何方便的将小程序转换成APP

Geek_99967b

小程序 小程序容器

UI自动化测试框架搭建-优化企业微信通知

伤心的辣条

Python 程序员 软件测试 自动化测试 UI自动化

3 个技巧来破解你可以立即使用的 Flutter 生产力!

坚果

6月月更

养老金融政策频出,市场有多大?

易观分析

养老消费

信用卡业务愈卷愈烈,银行机构如何突围?

易观分析

信用卡业务

在万家灯火阑珊处,重新认识平板电脑

脑极体

让你驱动力开机工作了,不是在待机状态。

叶小鍵

换掉bpmn-js,让前端更熟悉工作流业务

相续心

前端 流程图 workflow

Kent Beck建议超短项目跳过测试_研发效能_Mark Levison_InfoQ精选文章