让我们再聊聊TDD 续 – 人人都在做TDD

上一篇文章里面,通过对DHH的文章以及DHH和Kent Beck等讨论的分析,我阐述了对TDD的理解和分类,现在来继续聊聊TDD的实施和分层。

现在还有非常多的软件工程师在质疑TDD的可行性,比如太难不会、成本太高无法推动、意义不是很大等,但是他们却一直都在做着TDD,只不过没有意识到而已,这便是“不识庐山真面目,只缘身在此山中”。

TDD的实施一般分为思维层面和技术层面。一般来说,思维层面上的实施成本较低、容易接受,但是缺点很多,比如难以传递、难以持续获得快速反馈等;而技术层面上的实施一般成本较高、不容易被人接受,但是优点更多,比如可以获得快速反馈、更容易传递和协作等。而现实世界中TDD的实施一般分为三个阶段,即无意识的TDD、被动通过技术实现的TDD、以及有意识和主动通过技术实现的TDD。

第一阶段:无意识的TDD

对于软件开发人员,当他们拿到一个新的软件需求时,首先会思考如何实现,其中包括当前软件架构、业务分解、实现设计、代码分层、代码实现等。然后通过思考和设计所得到的产出物来驱动代码实现,进而在代码实现中会思考如何通过一个或多个函数或者算法来实现业务逻辑。所以软件系统的实现要先通过意识层面的思考,再进行技术层面的工作。

当开发人员思考和设计这些函数或者方法的时候,一般都会思考它们有哪些参数,然后想象将这些参数换成真实的数据后传递进去,会得到怎样的返回值。好一点的开发人员会思考如何处理异常输入和异常返回值。

这类思考其实已经是意识思维上的TDD,它帮助开发人员先在大脑里面设计并验证代码实现,甚至帮助其重构代码。所以很多开发人员都在无意识的情况下做着TDD。

比如在一个银行系统里面,开发人员拿到一个需求,需要开发一个通过手机APP转账的功能。

  1. 首先开发人员会基于当前的软件架构思考:是开发一个全新的模块来处理这个业务?还是基于当前架构中的某个模块来添加代码进行处理?
  2. 当确定架构和设计之后,就开始思考具体的代码实现,比如类的设计、方法的设计或者函数的设计等。当开发“将钱从原帐号转出”这个功能前,开发人员会思考:这个功能需要支持当钱从原帐号中转出成功后,原帐号中的余额等于原始余额减去转出金额。进一步有些程序员还会设计一些用来验证功能的实例,比如帐号中的原始余额是999.99,转出111.11,那么剩余的金额就应该是888.88。
  3. 在这样思考之后,开发人员便开始根据自己大脑中的测试逻辑和用例来驱动和辅助开发过程。在代码开发完毕之后还会想一些办法来验证一下所实现的功能是否符合预期,比如人工使用之前的或者新的测试用例再测试一下。如果验证正确,就会认为自己开发的功能正确了,并交给测试人员进行测试。

其实开发人员在开发前思考测试逻辑和用例的过程就是在做TDD了。

很多做业务分析的BA和测试分析前移的QA也同样在无意识的做着TDD(注:在前一篇文章中已说明TDD包含ATDD),比如分析验收条件、写出验收文档等。只不过这些AC和验收文档可能写得不是很明确或者不是很好,比如不是实例化需求等,但是本质上已经是TDD了。

只不过是初级的无意识的TDD,可能有的人做得好,有的人做得不好,而且没有明确的产出来协助和规范这个测试驱动开发方式,也缺乏快速反馈、度量、传递和协作等。因此从无意识到有意识将是做好TDD的一个重要过渡。

第二阶段:被动通过技术实现TDD

当有一部分软件工程师意识到了TDD的意义和普遍存在性之后,就开始准备解决思维上的TDD的缺点。而解决这些问题的方法就是在技术层面上用代码来实现TDD,用明确的代码来协助和规范开发人员的测试驱动开发行为,来度量他对业务逻辑以及代码实现的理解度。通过将他的理解传递给以后的维护人员,让他的理解能重复被使用,以及和其他人协作开发。

但是现实中很多开发人员的认识不足以及技术能力不够,就算管理层支持并且主动推动TDD,最终由于开发人员设计和选取的测试用例合理性很差,导致驱动出来的代码有效性差,测试用例无法体现出SBE(Specification by example)导致易读性差,对于自动化测试框架和测试编写不熟悉导致开发速度很慢等,往往是被动的在技术层面上去实现TDD,所以出现了各种怨言,各种抵触,进而导致技术层面上的TDD很难以大规模实施。

由于意识层面上的难易程度和工作量都比技术层面上相对较小,所以前者实施起来相对容易一些,而后者则相对较难,所以如果通过了各种手段强行实施TDD,而没有主动去摆正做TDD的意识,甚至没有足够的技术能力,那么这样的TDD就是一个倒三角,非常容易倒塌。

TDD倒三角

所以,如果不希望技术层面上的TDD随时倒塌,就需要把这个倒三角补全,才能更好的、长久的实施TDD。

第三阶段:有意识和主动通过技术实现TDD

为了大规模以及有效的实施TDD,首先要突破思维意识的局限,认识到TDD的普遍存在性和适用性,不要害怕和排斥TDD这种思维和开发模式。

其次要主动学习,并刻意练习TDD的技术实现,提升自己的技术能力,从而在技术层面能更容易的实现TDD,摆脱被动TDD的困境。其中学习的方法包括阅读TDD相关的书籍和文章,书籍包括《测试驱动开发》、《重构》、《BDD In Action》以及《系统思考》等,从而充分理解TDD优点和局限。

对于刻意练习,一定要长时间坚持去做,让其成为一种习惯。如果在项目中没有合适的环境去练习,还可以通过一些第三方的TDD练习系统去做刻意练习,比如Cyber-dojo。只有大量的刻意练习才能让你在真实的代码编写过程中去思考和理解TDD,去运用你通过学习得到的知识,最终才能做到有意识和主动的通过技术去实现TDD,TDD的倒三角才能变成一个稳定的砖块,然后哪里需要往哪里搬。

TDD砖块

总结

综上,大部分开发人员都应该在做TDD,只不过他们是无意识的或者被动的去实现的,只有少部分是有意识和主动的去实现的。既然人人都在做TDD,那么我们为什么不能和黑客帝国里面的Neo一样选择红色药丸来认清楚现实,主动拥抱TDD,并通过大量的刻意练习去改变自己的工作习惯,让TDD成为自己工作习惯的一部分,这样才能更好的提升软件质量,大大降低软件维护成本。不管你信不信,反正我信了。


更多精彩洞见,请关注微信公众号:思特沃克

Share

让我们再聊聊TDD

最近几年“TDD已死”的声音不断出现,特别是David Heinemeier Hansson那篇文章——《TDD is dead. Long live testing. (DHH)》引发了大量的讨论。其中最引人注目的是Kent Beck、Martin Fowler、David三人就这个举行的系列对话(辩论)——Is TDD Dead?

当前国内对TDD的理解十分模糊,大部分人也没有明确和有意识的去实施TDD,因此许多人对此都有着不同的理解。

其中最经典的理解就是基于代码的某个单元,使用Mock等技术编写单元测试,然后用这个单元测试来驱动开发,抑或是帮助在重构、修改以后进行回归测试。而现在大部分反对TDD的声音就是基于这个理解,比如:

  • 工期紧,时间短,写TDD太浪费时间;
  • 业务需求变化太快,修改功能都来不及,根本没有时间来写TDD;
  • 写TDD对开发人员的素质要求非常高,普通的开发人员不会写;
  • TDD 推行的最大问题在于大多数程序员还不会「写测试用例」和「重构」;
  • 由于大量使用Mock和Stub技术,导致UT没有办法测试集成后的功能,对于测试业务价值作用不大
  • ……

总结一下,技术人员拒绝TDD的主要原因在于难度大、工作量大、Mock的大量使用导致很难测试业务价值等。

这些理解主要是建立在片面的理解和实践之上,而在我的认知中,TDD的核心是:先写测试,并使用它帮助开发人员t来驱动软件开发。

首先是先写测试,这里的测试并不只是单元测试,也不是说一定要使用mock和stub来做测试。这里的测试就是指软件测试本身,可以是基于代码单元的单元测试,可以是基于业务需求的功能测试,也可以是基于特定验收条件的验收测试。

其次是帮助开发人员,主要是帮助开发人员理解软件的功能需求和验收条件,帮助其思考和设计代码,从而达到驱动开发的目的,所以TDD是包含两部分:ATDD与UTDD

ATDD(Acceptance Test Driven Development):验收驱动测试开发,首先BA或者QA编写验收测试用例,然后Dev通过验收测试来理解需求和验收条件,并编写实现代码直到验收测试用例通过。

由于验收方法和类型也是多种多样的,所以根据验收方法和类型的不同,ATDD其实是包含BDD(Behavior Driven Development)、EDD(Example Driven Development),FDD(Feature Driven Development)、CDCD(Consumer Driven Contract Development)等各种的实践方法。

比如以软件的行为为验收标准,这个是BDD;如果以特定的实例数据为验收标准,这个是EDD;如果以Web Service API消费者提出API契约来驱动API提供者开发API,这个是CDCD等。所以ATDD的具体实现需要结合项目的实际情况来选用适合的验收测试方法与类型。

UTDD(Unit Test Driven Development):单元驱动测试开发,首先Dev编写单元测试用例,然后编写实现代码直到单元测试通过。这个就是现在很多人所谓的TDD、实践的TDD、喜欢的TDD、抱怨的TDD,但是它却只是真正意义上TDD的一部分而已。

TDD金字塔

再来看看David 的《TDD is dead. Long live testing》,他主要是认为TDD大量使用mock,导致无法测试软件连接了数据库之后的功能,进而无法测试其业务价值。

其次他提出应该使用”Long live testing”, 而他并没有说明这种测试应该是在编写代码之前还是之后写,以及会不会用来作为客户对于软件的验收标准。如果他没有这样做,那他只是使用”Long live testing”来做回归测试;如果他做了,那么他也是使用了ATDD,从而使用了TDD。

所以他对TDD的理解还是狭隘的,认为TDD只是UTDD,导致他写了这篇文章来批评TDD。有可能他在现实工作中已经使用了ATDD,也就是TDD。

最后来看看Kent Beck、Martin Fowler、David关于Is TDD Dead?的辩论,我觉得他们所说的都有道理,并且也是合理的。原因是他们的背景和行业不同,本来对于不同的行业和不同的背景就应该选择适合的测试驱动方法(有可能不一样)。

首先来看看Kent Beck,他在Facebook工作,出版过很多书,可以定位为一名在大型IT公司工作的软件思想家。其次是David,一个标准欧洲帅哥,ROR创造者之一,Basecamp公司的创始人和CTO,Basecamp是一个只有几十个人的小型软件公司,所以他可以定位是一名创业者、技术牛人。

Kent Beck所在的公司开发的是大型复杂业务软件(Facebook平台),代码量巨大,需要长时间(几年)大量人员(几十甚至几百)来开发和维护。DHH开发的中小型企业软件(比如CRM),代码量一般,需要快速(几个月)、少量人员(几个到十几个)开发和维护。

Kent Beck在金钱和人力资源相对充足、时间相对充裕的情况下追求的是代码质量,大量人员的良好协作与平台稳定。DHH却在金钱和人力资源相对较少情况下追求最大化客户业务价值,使得少量人员能快速开发出软件并卖给客户赚钱。

所以在Kent Beck所在的环境下,单元测试(UTDD)是非常有价值的;而在DHH所在的环境下,功能测试或者ATDD却更为适合。

国内很多人对于TDD的狭隘理解还源于很多网上的中文资料,百度百科对于TDD的解释就是其中一个:

“TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践,但不只适用于XP(Extreme Programming),同样可以适用于其他开发方法和过程。”

而国外有不少站点上的资料是对于TDD是有正确理解的,比如下图是一个敏捷调查表。从其中的“We take a test-driven development(TDD) approach”和”We take a TDD approach at the requirements level”就能发现其对TDD的理解就是包含UTDD和ATDD。

TDD不是银弹,不要期望它能轻易解决你的问题,无论是UTDD、EDD还是BDD,根据自己项目的实际情况,比如资金、人力资源、时间、组织架构等,合理的选择。

今天我们又聊了聊TDD,也希望大家重新理解一下,重新思考和尝试一下,然后你会发现另外一片云彩。

TDD并没有死,死的是你的持续学习、思考、实践与总结。当前国内很多软件开发人员对于TDD的理解比较模糊,大部分人也没有明确和有意识的去实施TDD,因此很多人都有着不同的理解。


更多精彩洞见,请关注微信公众号:思特沃克

Share