邯郸网站建设唯辛ls15227,黑镜wordpress主题,做网站的产品图片,简约大气网站欣赏测试驱动开发#xff08;Test-Driven Development#xff0c;简称TDD#xff09;是敏捷开发模式中的一项核心实践和技术#xff0c;也是一种设计方法论。TDD有别于以往的“先编码#xff0c;后测试”的开发模式#xff0c;要求在设计与编码之前#xff0c;先编写测试脚本…测试驱动开发Test-Driven Development简称TDD是敏捷开发模式中的一项核心实践和技术也是一种设计方法论。TDD有别于以往的“先编码后测试”的开发模式要求在设计与编码之前先编写测试脚本或设计测试用例。 一、TDD概念
敏捷开发大师Kent Beck在1996年提出了极限编程Extreme Programming简称XP。TDD是其四个核心实践之一。【注参见【架构基础】简单设计原则】
TDD在敏捷开发模式中被称之为“测试优先的编程test-first programming”而在IBM Ration统一过程Rational Unified ProcessRUP中被称为“测试优先的设计test-first design”。所有这些都在强调“测试先行”使得开发人员对所做的设计或所写的代码有足够的信心同时也有保障地进行设计或代码的快速重构有利于快速迭代、持续交付。重构的前提就是测试就绪testing is ready在这样的前提下重构的风险就很低否则就会存在比较高的风险。 TDD具体实施过程可以嵌入到两个层次如下图所示
狭义TDD在代码层次在编码之前写测试脚本可以称为单元测试驱动开发Unit Test Driven Development简称UTDD。广义TDD在业务层次在需求分析时就确定需求的验收标准即验收测试驱动开发Acceptance Test Driven Development简称ATDD。 二、UTDD
先来谈谈UTDD基本流程如下图所示。
红RED在做某个新需求时先不着急编写功能代码而是把需求涉及的场景、约束等考虑清楚先写好测试用例。然后执行单元测试代码结果自然是不通过失败。绿GREEN利用单元测试的失败反馈查明功能代码未通过测试用例的原因针对性地添加或修改代码直到测试用例通过。重构REFACTOR在所有单元测试用例执行成功的基本前提下识别代码或设计上的坏味道进行重构。通过现有的单元测试用例来保证重构的正确性。 UTDD的三条规则
规则1 除非是为了使得一条失败的unit test通过否则不允许编写任何功能代码。
违反第1条先编写了功能代码那这段代码是为了实现什么需求呢怎么确保它真的实现了呢
规则2 在一个单元测试中只允许编写恰好能够导致失败的测试代码。
违反第2条写了多个失败的测试用例如果长时间不能通过测试会增加开发者的压力。另外测试可能会被重构这时会增加测试的修改成本。
规则3 只允许编写恰好能够使一条失败的unit test通过的功能代码。
违反第3条功能代码实现了超出当前测试的功能那么这部分代码就缺少测试的防护不确定是否正确需要额外增加手工测试。可能这是不存在的需求那就凭空增加了代码的复杂性。如果是现实存在的需求那后面的测试用例写出来就会直接通过破坏了UTDD的节奏感。
UTDD从根本上改变了开发人员Developer简称DEV的思维方式DEV不能再像过去那样随意地写代码要求所写的每行代码都是有效的代码写完所有的代码就意味着真正完成了开发任务。而在此之前所谓的代码写完了实际上只是完成了一半的工作因为单元测试还未执行可能会存在许多缺陷。
UTDD有力地促进DEV去思考需求的应用场景、异常处理或约束写出更加完善的功能代码。其次UTDD确保了测试的独立性。如果先写功能代码再进行测试容易受到实现思维的影响。多数情况下DEV自测时存在两大障碍思维障碍和心理障碍前者会导致DEV无法保证测试的客观性和全面性后者会导致DEV对自己的代码不愿深究即使发现了一些疑问也很可能会适可而止。
最后UTDD确保了所有功能代码的可测试性彻底地保证了代码的微观质量最终实现了可测试的系统。 三、ATDD
通常在一个大型项目中推行UTDD比较困难而在业务层面推行ATDD即在设计与开发之前明确需求特性的验收标准则相对比较容易推广实施。
在敏捷开发模式中由需求拆分出来的用户故事User Story简称US一般描述简单不具备可测试性。 举个例子
开发一个在线旅游APP提供交通、酒店、景点门票等预订服务有一个最基本的US作为一名旅游用户想通过一次操作快速删除事先预订的订单包含机票、酒店和门票。
对于这种US如果不附加验收标准DEV实现起来很容易在数据库的某个表中删除一条记录在其他关联表上修改相应的标志位即可。但实际业务不会如此简单订单说取消就取消不需要有一个取消的时间提前量取消一定成功吗是否要收取手续费是否需要线下处理时间是否需要通知用户采用何种方式通知用户取消成功或失败
回答上述问题就需要增加“验收标准”如
订单取消之前需要提醒用户再次确认提示用户需要提前24个小时取消订单取消需要4个小时处理时间才能确定取消成功与否订单取消需要收取总金额10%的手续费不管取消成功与否采用邮件和短信双重通知用户事后可以查询订单取消的记录需要保留客户和APP双向操作记录日志
如此US就具备了可测试性DEV也更明白如何去实现实现的结果和产品经理的期望更容易达成一致。 从ATDD演化出一种可具体落地的开发模式就是行为驱动开发Behavior Driven Development简称BDD。BDD最初是由Dan North在2003年命名它包括验收测试、客户测试驱动等XP实践。作为对TDD的回应主要是从用户的需求出发强调系统行为。BDD将验收标准进一步明确化可看作是ATDD的实例化即列出US涉及的应用场景并表达为Given-When-Then范式
Given给定什么上下文/条件 AND/OR 其他条件When当什么事件被触发Then产生什么结果 AND/OR 其他结果 BDD再往前推进一步就是需求实例化Requirements By Example简称RBE更加明确需求的具体表现。需求描述越明确需求干系人用户、产品经理、DEV与TSE等之间的理解就越趋近一致不容易产生偏差或误解有利于开发和测试的工作。基于RBEDEV编写需求的功能代码TSE可以独立编写测试代码产品经理的工作也会变得轻松不需要太多的解释不需要回答开发与测试的各种问题。
从需求角度看BDD和需求实例化比较彻底地明确需求统一用户、产品经理、DEV与TSE等人员的认知让大家在同一个层面上沟通使得研发工作更高效。从测试角度看需求即测试产品的需求就是测试的需求需求可以被执行即一步到位将需求变为自动化测试脚本开发出来的功能特性随时可以被验证。 TDD一改以往的破坏性测试的思维方式提倡“测试先行”更符合“缺陷预防”的思想。这样一来开发的思维方式发生了很大的变化编写出高质量的功能代码去通过这些测试在进行每一项设计、编写每一行代码时都要想想用户的真实需求、应用场景和一些例外情况等确保实现的功能特性符合预期并具有健壮性。测试也从以前的破坏性的方法转移到一种建设性的方法中来。在这种积极心态的影响下DEV的工作效率和产品代码的质量都会显著地提高真正实现“质量是内建的Quality is built in”的目标。 四、TDD的价值
TDD从业务层次需求分析、软件设计促进做正确的事即设计出符合用户需求包括功能需求与非功能需求的软件特性。
TDD从代码层次软件开发、软件测试促进正确地做事即开发出与设计完全一致的软件功能。
TDD充分体现了“测试先行小步迭代快速反馈”的敏捷思想从微观代码到宏观系统均践行着“要想跑得快先要跑得稳”的目标。
