search

cuixiaorui / chunquchunyoulai

随便记录点啥（个人博客）
45 stars 13 forks source link

对 TDD 的理解 #8

Open cuixiaorui opened 4 years ago

cuixiaorui commented 4 years ago

行为驱动开发(BDD)：定义系统的行为是主要工作，而对系统行为的描述则变成了测试标准

TDD 怎么实施

自底而上分析

如果你一开始，就去碰 Unit Test , 跪 - 噶嘣脆

为了Unit Test , 你需要 TDD 的套路，问题就变成 测试用例 有哪些，边界在哪，从哪来？

要得到适当的测试用例 (测试用例不是越多好), 你就需要验收标准， 验收标准从哪里？

要 验收标准 ，就需要 用户故事

举个例子：

把大象放进冰箱 （验收标准 BDD）

如何满足呢

拆分步骤

  1. 打开冰箱门
  2. 把大象放进去
  3. 关上冰箱门

单测就是基于这个拆分步骤形成

接着对 1.2.3 步骤一一加单测即可

如果步骤 1.2.3.还是太大 那可以递归进行拆分

感想

写 TDD 和我们在生活里去完成一件事情一样。

首先，我们需要先确定要完成的事情是什么(目标) --> 验收标准

接着，我们把目标拆分成小步可测量的行动 --> unit test

然后，把小步可测量的行动完成 --> 通过测试

最终，我们完成了我们的目标

这一套思想看来不管是放在编程中，还是在日常的学习中都是相同的，而且其原理都是一样的。

cuixiaorui commented 4 years ago

结对编程

如何在团队内实时结对编程

  1. A 写 test
  2. B 写 code to make test pass
  3. A 再去 refactor B

角色互换很重要。

如何带新人结对编程

  1. 写个 test case, 让新人写实现，引导他如何通过 testcase
  2. 在让新人写 testcase , 引导他 test case该如何写，忍住，由他写。
  3. 然后你来写实现通过 testcase.
  4. 再进一步，让新人来提出 testcase, 你来写 test case. 他写实现
  5. loop
cuixiaorui commented 4 years ago

BDD、TDD之间的区别

  1. 高维度的，关注行为
  2. 低维度的，关注接口

开发角度

另一个角度

cuixiaorui commented 4 years ago

react TDD

  1. E2E
  2. UI 测到 dispatch() 转战 dva model （UI 逻辑）
  3. dva 测到接收 action，触发 effects，检测 state 变化 （redux-saga-test-plan）
  4. 回到 E2E
cuixiaorui commented 4 years ago

写代码只是让测试通过

写测试 = 设置游戏关卡

写代码 = 闯关

当测试通过的时候 = 闯关成功

闯关成功的时候感觉太爽了

cuixiaorui commented 4 years ago

流程

大需求

这一般是指产品经理给的需求，一个特别大的需求，也可以称为开发任务。

验收

由大需求转变为一个个验收条件（一般可以问 BA 或者产品经理来确认）着一步的重点在于沟通！！！

而整理出来的一个个验收条件就可以作为我们写程序的最外层的测试。这里称为 BDD 或者叫 ATDD（叫啥不重要）

用大白话来讲，就是说你这个功能怎么叫做完？那必须满足一个个条件，那么这一个个条件就是验收测试。

Tasking

这时候就需要先想，怎么才能搞定这个验收测试，分为几步才能搞定。

举例：

把大象放到冰箱：

着一步十分关键，也称为 tasking ，这个拆分的思想将会一直伴随着我们整个 TDD 过程

递归拆分

通过上一步的拆分，我们可以知道要做哪一步才能满足验收测试了。着时候就可以着手写单元测试了。这里还有一个重要的点在于，如果我们在写单元测试的时候发现当前的这个步骤太大，那么我们是可以递归的进行在 tasking 的！！！这个理解很重要很重要！！！

结束

当我们通过不断的递归，完成所有的小问题后，那么最外围的测试自然就搞定了。最终的 ATDD 测试通过就算任务完成

公式

大需求 = 验收测试1 + 验收测试2 + 验收测试3

验收测试1 = A + B + C

A = D + E + F

B = Q + W + E

C = x + y + z

这个过程无限递归，直到任务完成

任务拆分，分而治之

图形表示

。。。。没法搞上来 TODO

方法

思想

递归不断的把大问题分解成小问题，用分而治之的思想来解决最终的大问题，这个思路在算法上就有所体现，在 TDD 上也是一样。

其实 tasking 就是分而治之的思想体现。

测试

感想

理解了任务拆分

理解了递归

整个思路就算通了

剩下的无非是如何测试的问题，选择什么工具来测试

服务器怎么测试

  1. 先写集成测试
    1. 集成测试需要访问真实的数据库
  2. 在写对应的单元测试
    1. 关于数据库的访问统统 mock 掉