10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7940 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序员解决的问题,大多不是程序问题
免费
思考框架 (1讲)
01 | 10x程序员是如何思考的?
以终为始 (11讲)
02 | 以终为始:如何让你的努力不白费?
03 | DoD的价值:你完成了工作,为什么他们还不满意?
04 | 接到需求任务,你要先做哪件事?
05 | 持续集成:集成本身就是写代码的一个环节
06 | 精益创业:产品经理不靠谱,你该怎么办?
07 | 解决了很多技术问题,为什么你依然在“坑”里?
08 | 为什么说做事之前要先进行推演?
09 | 你的工作可以用数字衡量吗?
10 | 迭代0: 启动开发之前,你应该准备什么?
答疑解惑 | 如何管理你的上级?
划重点 | 关于“以终为始”,你要记住的9句话
任务分解 (11讲)
11 | 向埃隆·马斯克学习任务分解
12 | 测试也是程序员的事吗?
13 | 先写测试,就是测试驱动开发吗?
14 | 大师级程序员的工作秘笈
15 | 一起练习:手把手带你分解任务
16 | 为什么你的测试不够好?
17 | 程序员也可以“砍”需求吗?
18 | 需求管理:太多人给你安排任务,怎么办?
19 | 如何用最小的代价做产品?
答疑解惑 | 如何分解一个你不了解的技术任务?
划重点 | 关于“任务分解”,你要重点掌握哪些事?
沟通反馈 (12讲)
20 | 为什么世界和你的理解不一样
21 | 你的代码为谁而写?
22 | 轻量级沟通:你总是在开会吗?
23 | 可视化:一种更为直观的沟通方式
24 | 快速反馈:为什么你们公司总是做不好持续集成?
25 | 开发中的问题一再出现,应该怎么办?
26 | 作为程序员,你也应该聆听用户声音
用户故事 | 站在前人的肩膀上,领取属于你的高效工作秘籍
27 | 尽早暴露问题: 为什么被指责的总是你?
28 | 结构化:写文档也是一种学习方式
答疑解惑 | 持续集成,一条贯穿诸多实践的主线
划重点 | 一次关于“沟通反馈”主题内容的复盘
自动化 (12讲)
加餐 | 你真的了解重构吗?
29 | “懒惰”应该是所有程序员的骄傲
30 | 一个好的项目自动化应该是什么样子的?
31 | 程序员怎么学习运维知识?
32 | 持续交付:有持续集成就够了吗?
33 | 如何做好验收测试?
34 | 你的代码是怎么变混乱的?
35 | 总是在说MVC分层架构,但你真的理解分层吗?
36 | 为什么总有人觉得5万块钱可以做一个淘宝?
37 | 先做好DDD再谈微服务吧,那只是一种部署形式
答疑解惑 | 持续集成、持续交付,然后呢?
划重点 | “自动化”主题的重点内容回顾汇总
综合运用 (7讲)
38 | 新入职一家公司,怎么快速进入工作状态?
39 | 面对遗留系统,你应该这样做
40 | 我们应该如何保持竞争力?
答疑解惑 | 如何在实际工作中推行新观念?
划重点 | “综合运用”主题内容的全盘回顾
总复习 | 重新审视“最佳实践”
总复习 | 重新来“看书”
结束语 (1讲)
结束语 | 少做事,才能更有效地工作
10x程序员工作法
登录|注册

13 | 先写测试,就是测试驱动开发吗?

郑晔 2019-01-28
在上一讲中,我向你说明了为什么程序员应该写测试,今天我准备与你讨论一下程序员应该在什么阶段写测试。
或许你会说,写测试不就是先写代码,然后写测试吗?没错,这是一个符合直觉的答案。但是,这个行业里确实有人探索了一些不同的做法。接下来,我们就将进入不那么直觉的部分。
既然自动化测试是程序员应该做的事,那是不是可以做得更极致一些,在写代码之前就把测试先写好呢?
有人确实这么做了,于是,形成了一种先写测试,后写代码的实践,这个实践的名字是什么呢?它就是测试先行开发(Test First Development)。
我知道,当我问出这个问题的时候,一个名字已经在很多人的脑海里呼之欲出了,那就是测试驱动开发(Test Driven Development),也就是大名鼎鼎的 TDD,TDD 正是我们今天内容的重点。
在很多人看来,TDD 就是先写测试后写代码。在此我必须澄清一下,这个理解是错的。先写测试,后写代码的实践指的是测试先行开发,而非测试驱动开发。
下一个问题随之而来,测试驱动开发到底是什么呢?测试驱动开发和测试先行开发只差了一个词:驱动。只有理解了什么是驱动,才能理解了测试驱动开发。要理解驱动,先来看看这两种做法的差异。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(24)

  • 测试驱动不但可以写出精炼的代码,还能养成良好的编程习惯和设计思维, 相辅相成。
    团队达到这种状态还真是不易,架子搭好了有人觉得没发挥空间,要是放开了代码又会五花八门难以测试。莫名有种担心,会不会为了测试而测试在代码里混搭着workaround 呢?

    作者回复: 测试应该是什么样子,后面即将呈现,敬请期待!

    2019-01-30
    7
  • 邵俊达
    最近在一个新项目中尝试使用了 TDD 有测试保驾护航是真的爽。事情是这样的,今天经过讨论要把一个模型替换掉,刚听到这个消息的时候我是崩溃的,心想这要是出 bug 怎么办,到转念一想我测试覆盖率 88% 应该还好,动手改完跑起测试,果然不过,但是只是几个叫小问题,再次运行测试 绿灯!我的天,此时内心别提多么舒爽,这要是没有测试我今晚应该不用睡了,谢谢老师。最近也开始先分解任务再小步提交,这么做下来有一种很踏实的感觉,同事 review 代码也舒服很多。

    作者回复: 恭喜你,进步了!

    2019-04-17
    4
  • Sudouble
    之前在其他领域的里也有介绍负反馈相关单位内容,各个领域之间还是有很多互通之处。软件或者其他系统一直处于熵增的状态,需要持续的保养和维护。不得不感慨大道至简啊

    作者回复: 一通百通

    2019-02-11
    4
  • 彩色的沙漠
    阅读之后有了基本的认知,还需要阅读这方面的相关书籍和实践

    作者回复: 更重要的是练习

    2019-01-30
    4
  • 涛哥迷妹
    好感动哭了

    编辑回复: 这位同学,你是认真的吗😁

    2019-01-28
    3
  • 西西弗与卡夫卡
    印象最深的几次TDD。
    1. 是个CS应用,从服务端拉取数据后,根据不同状态,客户端执行不同逻辑。采用的方法是,将服务端的响应值记录,然后在测试代码里回放,不依赖服务端。修bug时,每个bug就是一个测试,测试代码里直接回放记录的服务端响应。好处是,回归非常快,而且不依赖服务端
    2. 上家公司要做HA软件开发,情况很复杂,手工做测试代价很高。正好赶上docker兴起,于是就写了很多“暴力”代码(比如直接kill服务、删除服务等)测试各种场景,只留少数必须用物理机测试的场景交给人工

    作者回复: 第一个像验收测试,第二个像暴力测试。

    2019-01-28
    2
  • andyXH
    以前理解的测试驱动开发,我写完测试、代码完成就结束了。看完文章,增加对重构理解。有了测试的依托,改动代码的结果也能从测试结果中看出。
    目前对于 TDD 还是处于理解状态,不知道如何真正的在项目工程中使用。因为项目工程往往还有很多其他调用,如rpc,数据库服务,第三方服务,不知道在这个过程如何处理。期待老师的之后文章讲解

    作者回复: 终于在综合运用模块答疑这个问题。

    2019-01-31
    1
  • liu
    以前以为测试驱动开发只是先写测试,再开发就完了。原来还有重构。想想也对。代码第一步完成功能表达,但未经重构的代码必然存在坏味道。重构,才能使代码机构清晰,便于理解阅读

    作者回复: 重构拯救代码!

    2019-01-28
    1
  • pyhhou
    感谢老师指点,之前没听过 TDD,但是知道 Unit Test 很重要,要随着写代码一起写,也没想过原来可以先写 test,后实现 code,这样 test 很自然地时刻存在在开发的每一个阶段。在 TDD 里面 “红——绿——重构” 中,看完老师这边文章对其中的 “红” 和 “绿” 都能理解,因为就是写 code,保证 code 可测并且能够通过所有 test,但是对这里的 “重构” 还是比较地困惑,“重构” 很重要,那么这里有没有什么方向性或者方法可言呢,因为仅仅看 “重构” 的定义,貌似和 test 没有直接的联系,test 只是保证能够更好的 “重构”,文章中只说了 “重构” 是为了消除 “冗余”,消除代码的 “坏味道”,那什么是 “冗余”,什么是 “坏味道”,具体该怎么定义 “重构” 需要解决的问题呢?还有 “重构” 怎样才能更好地执行呢?谢谢老师

    作者回复: 你可以看一下 Martin Fowler 的《重构》(https://book.douban.com/subject/4262627/),2018年第二版的英文版也已经出版了,其中文版的译者还是第一版的译者熊节。

    2019-01-25
    1
  • 丁丁历险记
    可测的代码往往符合类的单一原则。
    2019-11-07
  • 陈斯佳
    老师,运维写脚本也需要考虑测试吗?
    2019-07-24
  • 姚琪琳
    感觉TDD的时候很容易就写成了冰淇淋蛋卷的测试结构,因为不太可能去TDD某个类里的某个方法。而且感觉冰淇淋蛋卷对重构更友好,毕竟测试是端到端的,不在乎内部如何实现。
    2019-07-23
  • lu4nx
    有时别人写的文档比较模糊时,我会直接看测试用例去了解接口怎么用。
    2019-06-08
  • Yogurt
    PowerMock框架是可以支持mock static类和方法的

    作者回复: 但我不建议使用,因为它会把设计引导向一个错误的方向。如果是应对遗留代码,勉强可用。

    2019-06-03
  • 陈斯佳
    TDD的节奏是:红-绿-重构,先编写一个失败的测试,然后编写一个代码通过测试,最后消除冗余,消除代码的坏味道。写代码前先想想怎么测试,我们必须保证编写可测试的代码。
    2019-05-15
  • enjoylearning
    今天又被作者引入了测试先行的开发理念,一直觉得Tdd不一定要先写测试,完成功能代码再写测试也可以啊,用单元测试去验证写的逻辑,发现测试失败了,回去看代码实现,绿了再回去看代码坏味道。

    作者回复: TDD 的关键其实在于设计。

    2019-03-28
  • lyning
    TDD 还需要事先分析和任务分解,不然就变成为了 TDD 而 TDD 了

    作者回复: 开发就应该先做分析和分解,和TDD无关。

    2019-03-17
  • 红糖白糖
    TDD,和任务分解可以说是相辅相成。
    在写测试的时候,一个一个的case其实在对任务的分解,考虑每个case所要达到的目标,输入、输出,以及case与case之间的衔接。写测试的时候,我们是站在一个consumer的角度来的,考虑的是这个case的输入和输出。首先,这对于设计能力有一定的要求,其次,按照这种方式写出来的代码可用性更高。因为我们的起点是consumer 而不是provider
    2019-03-10
  • 姜浩远
    测试清单可以和DoD联系起来么?

    作者回复: 从实践的层面,这是两回事,如果你非要找二者的共性,也是有的。

    2019-02-06
  • ZackZzzzzz
    老师如果有机会的话,谈一谈对不同层面测试的理解吧。

    我们现在的后端代码库大概有三种层面的测试
    1.单元测试 - 对某个类的测试
    2.系统测试 - 测试service之间的interaction
    3. 我们还有一个container test, 测试方法是mock所有的external dependency数据库也好,其他的服务也好,这样能保证负责的业务逻辑从头到尾的结果

    老师你对测试的理解是怎么样的?什么应该被测试,大概投入多少比例

    作者回复: 其实,测试金字塔已经说了测试比例,越是底层的测试应该越多,只有尽可能多的单元测试才能有接近100%的覆盖率。

    2019-01-29
收起评论
24
返回
顶部