微信号:infoqchina

介绍:有内容的技术社区媒体

Q新闻丨为什么敏捷开发在亚洲实行不了;java单元测试框架之争

2016-07-09 08:58 Q新闻

为什么敏捷开发在亚洲实行不了?

“为什么敏捷开发在亚洲实行不了”这个话题近几年被讨论了很多。Joshua Partogi是scrum.org的一位资深敏捷教练,他最近就这个话题写了一篇文章,说亚洲的大多数银行都没有把敏捷开发推行得很彻底。

Partogi就为什么Scrum和敏捷在亚洲实行不了这个问题给出了一些解释。他说最主要的原因是大多数亚洲人都对现在的管理文化很熟悉很习惯,他们知道自己在组织中的角色,也知道在什么样的情况下该怎么办事。

有人希望有人告诉自己该干什么,也有人总想指挥别人干事,整个组织工作井然有序。

亚洲人习惯于和自己的伙伴保持和谐的关系,避免冲突,这就影响了亚洲的敏捷小组在从事敏捷开发时的工作方式,包括迭代计划、迭代回顾及日常敏捷工作等。据Partogi说,人们习惯于保留意见,因为他们无法适应一个他们可能会犯错误的环境,即使在这样的环境下犯错误也无所谓。

Claudio Caballero是Goodwill Group Foundation的CTO,他在博客里写过一篇文章《在亚洲推行敏捷开发遇到了大困难》,也提到了一个原因,就是亚洲人是羞于当面说出逆耳之言的。

敏捷开发需要大家当面直言问题所在,而这有悖于亚洲文化,因为亚洲人特别注意对别人表示尊重、给别人留面子,这一点与西方文化特别不同,而西方正是敏捷思想的发源地。

Ken Schwaber是scrum.org的创始人,也是Scrum的创造者之一,他在他的博客上提到了在中国推行敏捷思想的文化障碍。他提到那些关注可预见性的人们在敏捷环境下会遇到困难:

对于那些习惯了可预见性的人们来说,他们希望他们可以预见未来。那么他们的工作就是动用人力物力来使自己预见的未来成为现实。而具有敏捷思想的人们却深知对于软件研发这种复杂的、创造性工作的来说,可预见性这种事情是不可能的,结果通常是很糟的:软件质量差、计划延期、资金浪费和士气低迷等。

Partogi说亚洲的教育机制也影响了人们在工作中的思考方式和行为。

亚洲的教育完全都是为了考高分、定级别,而不是为了尝试、自我发现和试错,可这些却正是敏捷实践的目的所在。

Partogi说到因为很多公司都把项目外包到亚洲去,他们想通过采用敏捷来减少成本。可实际上敏捷需要非常高素质的队员,这些人恰好通常不便宜。那么只要大家仍然误以为转用敏捷开发方式会减少成本,在亚洲敏捷就推行不下去。

  • 本文翻译已获授权,原文链接:

  • https://www.infoq.com/news/2016/06/agile-asia

  • 本文译者:足下

Java单元测试框架之争

最近Reddit上的讨论帖引发了一场JUnit和Spock两个测试框架支持者之间的辩论,源起于Jakub Dziworski发表的博文,其中心思想是“JUnit有什么问题?”目前来看几乎每个GitHub仓库都引入了基于JUnit的单元测试,不过也难怪毕竟JUnit已经经历了超过15个年头。但是Spock正在持续蚕食市场。

JUnit由极限编程(eXtreme programming)创始人Kent Beck、《设计模式:可复用面向对象软件的基础》合著者Erich Gamma共同创造,并且很快变成单元测试领域的事实标准,被移植和克隆到几乎所有流行的编程语言中。然而,这些年来JUnit的的特性一直被新的单元测试框架质疑,例如TestNG和Spock。

TestNG

TestNG由《Java测试新技术TestNG和高级概念》合著者Cédric Beust于2004年创造。根据TestNG网站描述,“TestNG是从JUnit和NUnit汲取灵感的测试框架,但是引入了一些新的功能使其更加强大并且易于使用”。Beust在其自己的网站上写道,“我开始编写TestNG是出于无奈,JUnit有一些不足之处,这些问题我在博客的这里和这里进行了标注。”

Spock

Dziworski在博文中质疑了使用JUnit需要结合第三方mock框架。他表示,“在中型和大型Java项目中结合这些框架会是得读写测试变得更加困难。”他随后说道,“如果测试代码难以编写,开发者通常会将编写测试代码作为痛苦工作,并开始忽略它们。避免或者延迟编写测试代码会导致应用无法再被信任。最后开发者会害怕修改这些代码,因为应用的其他部分可能以某种奇怪的方式出现问题。”

在最近Java希腊用户组会议中,《Java测试框架Spock》的作者Kostis Kapelonis做了演讲,比较了JUnit和Spock。

Spock由Gradleware首席工程师Peter Niederwieser于2008年创建。虽然灵感来自于JUnit,Spock的特性不仅仅是JUnit的扩展:

  • 测试代码使用Groovy语言编写,而被测代码可以由Java编写。

  • 内置mock框架以减少引入第三方框架。

  • 可支持自定义测试件名称。

  • 为创建测试代码预定义了行为驱动块(given:、when:、then:、expect:等)。

  • 使用数据表格以减少数据结构的使用需求。

以下代码片段(和Reddit讨论中使用的相同)演示了部分特性的使用:

class Math extends Specification {    def "maximum of two numbers"(int a, int b, int c) {        expect:        Math.max(a, b) == c        where:        a | b | c        1 | 3 | 3   // passes        7 | 4 | 4   // fails        0 | 0 | 0   // passes    } }

这个简单的测试示例使用了两个预定义的块,expect:(第三行)和where:(第五行)。where:块用于定义数据表格,用于映射第四行定义的Math.max函数的期望输入输出。第二行演示了如何为测试用例自定义一个名称。

一个包含JUnit和Spock代码示例的完整项目可以在GitHub上查看。

早在2008年InfoQ就报道了关于JUnit灭亡的一些猜想。八年后JUnit 5项目仍然健在,里程碑1正在开发中。测试框架的利好和繁荣!

  • 本文翻译已获授权,原文链接:

  • https://www.infoq.com/news/2016/06/Junit-vs-Spock

  • 本文译者:金灵杰


【GTLC重磅演讲嘉宾 】8月29日~30日 全球技术领导力峰会 上,普元信息CTO焦烈焱将为您揭秘“数字化经济下技术领导者如何洞察创新”。8折售票正在进行,快戳阅读原文

延展阅读(点击标题):


本文系InfoQ原创首发,未经授权谢绝转载。

 
InfoQ 更多文章 敏捷已死?错!3招助你炼出一个更好的技术团队! 包建强:为什么我说Android插件化从入门到放弃? Google为什么要把数十亿行代码放到一个库中? 系统性能卡又慢?这十大性能错误你都检查了吗? 异地多活设计难?其实是你陷入了这四大误区出不来!
猜您喜欢 打造S级手游,腾讯WeTest品质把控2016ChinaJoy HTTP协议漫谈 立等可取:工具定制让Oracle优化变得更简单快捷 Paxos理论介绍(1): 朴素Paxos算法理论推导与证明 用JS给option添加“选中”属性