软件敏捷开发 TDD 方案

拾贰 2019-08-26 AM 1450℃ 2条

前言

现在开发软件都讲敏捷开发,何为敏捷开发?敏捷开发是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重做为软件开发中人的作用。但是现在敏捷开发又好几种方案,如:TDDBDDDDDATDD

几种模式的介绍

TDD:测试驱动开发(Test-Driven Development)

测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论,TDD首先考虑使用需求(对象、功能、过程、接口等)。主要是编写测试用例框架对功能的过程和接口进行设计,而测试框架可以持续进行验证。大行其道的一些模式对TDD的支持都非常不错,比如MVC和MVP等。

BDD:行为驱动开发(Behavior Driven Development)

BDD也就是行为驱动开发。这里的B并非指的是Business,实际上BDD可以看作是对TDD的一种补充,让开发、测试、BA以及客户都能在这个基础上达成一致,JBehave之类的BDD框架。

ATDD:验收测试驱动开发(Acceptance Test Driven Development)

通过单元测试用例来驱动功能代码的实现,团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。

DDD:领域驱动开发(Domain Drive Design)

DDD指的是Domain Drive Design,也就是领域驱动开发,DDD实际上也是建立在这个基础之上,因为它关注的是Service层的设计,着重于业务的实现,将分析和设计结合起来,不再使他们处于分裂的状态,这对于我们正确完整的实现客户的需求,以及建立一个具有业务伸缩性的模型。

TDD 实施方案

通过测试来推动整个开发的进行,但测试驱动开发并不只是单纯的测试工作,而是把需求分析,设计,质量控制量化的过程。

开发原则

先写测试代码后,再写功能代码。

  1. 根据需求文档编写测试代码,并非实现功能;
  2. 不要想一口吃成胖子,对大的功能块测试时应该先分拆成更小的功能块进行测试;
  3. 切记不能为完成功能而写代码,用尽可能简单的代码实现功能;
  4. 需求能够测试的,就写测试代码,不能测试的或觉得不需要测试的一律放弃;
  5. 在改/加任何功能代码前,一定要先想是不是要改/加测试用例;
  6. 功能/测试代码,结构不合理,重复代码等情况,在测试通过后,及时进行重构。

TDD的开发流程

  1. 分析并确定一个目标测试场景;
  2. 添加一个单元测试来验证该测试场景的输入输出;
  3. 运行该测试,得到失败的测试结果;
  4. 写最简单的功能代码来通过该测试;
  5. 再次运行该测试,看到测试通过;
  6. 进行代码重构,包括功能代码和单元测试代码;
  7. 重复以上步骤,直至开发完成。

TDD 的好处

  1. 降低开发者负担。通过明确的流程,让我们一次只关注一个点,思维负担更小。
  2. 保护网。覆盖完全的单元测试,对产品代码提供了一个保护网,让我们可以轻松地迎接需求变化或改善代码的设计。所以如果你的项目需求稳定,一次性做完,后续没有任何改动的话,能享受到 TDD 的好处就比较少了。
  3. 提前澄清需求。先写测试可以帮助我们去思考需求,并提前澄清需求细节,而不是代码写到一半才发现不明确的需求。
  4. 快速反馈。有很多人说 TDD 时,我的代码量增加了,所以开发效率降低了。但是,如果没有单元测试,你就要手工测试,你要花很多时间去准备数据,启动应用,跳转界面等,反馈是很慢的。准确说,快速反馈是单元测试的好处。

为什么很多人做 TDD 都做不起来?

  1. 不会合理拆分任务。TDD 之前要拆分任务,把一个大需求拆成多个小需求;也可以拆出多个函数来。
  2. 不会写测试。什么是有效的单元测试,有很多人写测试,连到底在测什么都不清楚,也可能连断言都没有,通过控制台输出,肉眼对比来验证。好的单元测试应该符合几条原则:

    • 简单,只测试一个需求
    • 符合 Given-When-Then 格式
    • 速度快
    • 包含断言
    • 可以重复执行

Given 一个上下文,指定测试预设;When 进行一系列操作,即所要执行的操作;Then 得到一系列可观察的后果,即需要检测的断言

  1. 不会写刚好的实现
    很多人写实现的时候无法专注当前需求,一不小心就把其他需求也实现了,就破坏了节奏感。实现的时候不会小步快走。
  2. 不会重构。不懂什么是 Clean Code,看不出 Smell,没有及时重构,等想要重构时已经难以下手了。不知道用合适的「手法」消除 Smell
  3. 基础设施。对于特定技术栈,没有把单元测试基础设施搭建好,导致写测试时无法专注在测试用例上。

拒绝拖延(感谢关注)

公众号:前端讲堂

公众号ID:js-say

标签: none

非特殊说明,本博所有文章均为博主原创。

上一篇 Mac 使用 IDEA 写第一个 Spark 程序
下一篇 没有了

评论啦~



已有 2 条评论


  1. test
    test  Windows 10 x64 Edition Google Chrome 76.0.3809.87

    test

    回复 2020-05-11 11:18
  2. 阿松大
    阿松大  Windows 10 x64 Edition Google Chrome 70.0.3538.25

    阿松大

    回复 2020-06-01 08:29