10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7943 人已学习
课程目录
已完结 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程序员工作法
登录|注册

12 | 测试也是程序员的事吗?

郑晔 2019-01-25
在“任务分解”这个模块,我准备从一个让我真正深刻理解了任务分解的主题开始,这个主题就是“测试”。
这是一个让程序员又爱有恨的主题,爱测试,因为它能让项目的质量有保证;恨测试,因为测试不好写。而实际上,很多人之所以写不好测试,主要是因为他不懂任务分解。
在上一个模块,我们提到了一些最佳实践,但都是从“以终为始”这个角度进行讲解的。这次,我准备换个讲法,用五讲的篇幅,完整地讲一下“开发者测试”,让你和我一起,重新认识这个你可能忽视的主题。
准备好了吗?我们先从让很多人疑惑的话题开始:程序员该写测试吗?

谁要做测试?

你是一个程序员,你当然知道为什么要测试,因为是我们开发的软件,我们得尽可能地保证它是对的,毕竟最基本的职业素养是要有的。
但测试工作应该谁来做,这是一个很有趣的话题。很多人凭直觉想到的答案是,测试不就该是测试人员的事吗,这还用问?
测试人员应该做测试,这是没错的,但是测试只是测试人员的事吗?
事实上,作为程序员,你多半已经做了很多测试工作。比如,在提交代码之前,你肯定会把代码跑一遍,保证提交的基本功能是正确的,这就是最基本的测试。但通常,你并不把它当成测试,所以,你的直觉里面,测试是测试人员的事。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(22)

  • 西西弗与卡夫卡
    我有个执念,不愿主动写测试代码的程序员,不太可能是优秀的程序员

    作者回复: 我认同你的说法

    2019-01-25
    22
  • 张飞洪
    团队认知,开发周期,软件和生命财产关系不大,是单元测试的拦路虎

    作者回复: 还有一点是,知识,很多人不愿意写测试的原因是不会写测试。

    2019-01-25
    9
  • Johnsen 
    像前端项目主要以UI为主,版本迭代速度又很快的情况下怎么进行单元测试的编写

    作者回复: 首先,迭代速度快慢与是否写测试没关系,取决于工作是否完成是前面提到的 DoD。其次,前端之所以能够在今天成为一个独立的项目,在于它有大量的逻辑需要写,如今 JavaScript 相关的测试框架已经发展得很完整了,就按照正常的方式去写测试就好了。

    2019-01-25
    5
  • 🌲树根🌲
    我的想法可以在复杂度高,重要核心的模块先开始写单元测试。特别是公用、底层的,因为这些靠功能测试很难覆盖。

    单元测试难以推行主要是没有碰到质量的痛点,通常都依靠测试工程师来保证质量。我们之前就在遇到过质量崩塌,倒逼着我们去做,以保证质量。

    作者回复: 很多人不知道质量问题是一环套一环累积起来的。

    2019-02-02
    3
  • 苦行僧
    最近深有感触 单元测试写的越多 越能反思自己的代码 内建质量也能一步步建立起来 多写单元测试真是会产生蜕变的

    作者回复: 小病不治,会生大病的。

    2019-03-29
    2
  • helloworld
    老师我有几个疑问:1. 单元测试是不是也要随着业务流程的变化而要持续维护?2. 对于变动非常频繁的业务流程是不是可以不写单元测试?因为考虑到时间的问题。3. 所有的大公司重要的项目(例如淘宝,京东等平台)是不是都有严格的单元测试编写或者执行规范?谢谢老师啦。

    作者回复: 1和2,本质上是一个问题。其实,很多人担心写测试会影响写代码,但实际上,写测试,尤其是单元会帮助写代码,否则,你用的手工测试或系统测试的方式来保证系统的正确性。如果你不花练习写测试,你永远学不会写测试,写测试在你看来就是浪费时间。

    这背后其实还隐藏着另外一个问题,为什么会变化快?因为一方面,前期的工作做得少,这是我们前面讲的内容要解决的,另一方面,设计做的不好,变化都是大变化,设计不做好,那就到处是问题,这是我们后面要讲的内容。

    3,国内公司在工程上做得都不够好,如果想看好榜样,可以看看国外的公司,比如,Google,它要求100%测试覆盖率。

    2019-02-26
    2
  • One day
    从一个以前基本不写j测试代码的我,不过基本都有自动化测试以及测试人员,现在也开始写自己的代码的那部分测试,最开始的不情愿,到现在一直写,并且我会一直写下去,觉得这个是一种验证,每次看到自己写的代码再用自己写的测试通过之后信心满满呐

    作者回复: 坚持是蜕变的基础,加油!

    2019-01-30
    2
  • 团队开发人员的编程功力不够,即使想写单元测试也是奢望。那种前后台代码不分,用着先进的设计模式但写着落后方式实现的代码的,一旦开始了单元测试,估计大部分时间不是在实现上而是在频繁修改单元测试代码上了。

    作者回复: 说得有道理,不过,在接下来的几篇,我们先把关于测试的理念梳理顺了,知道问题出在哪,以后才好进行改进。

    2019-01-25
    2
  • wesleydeng
    现在单元测试有很多涉及到资源(比如db)的测试,这种情况下往往有依赖spring,导致了两个问题:
    1.spring启动慢
    2.dao测试不能跨环境,导致竟然因为有dao用了junit,不方便批量运行
    junit这两个问题怎么破?

    作者回复: 首先,涉及到Spring启动,这是集成测试,不是单元测试。
    其次,Spring提供了数据库的测试方案,测试之后,可以回滚,测试之间彼此不影响。用spring和test作为关键字可以搜到。
    再次,我个人推荐使用Spring Data,自己少写数据库逻辑。

    2019-06-17
    1
  • Geek_fe0336
    请教老师一个具体问题,mvc结构的工程,c层的单元测试要实际的去调用m层吗?需要和数据库里的数据做比对和验证吗?如果不用,c层的单元测试应该验证或测试哪些内容呢?

    作者回复: 在单元测试里,M 的接口是可以用 Mock 的,这才算是单元测试。涉及到数据库,就变成了集成测试。

    2019-03-21
    1
  • Lyam📵
    服务划分与编排做不好的、搞不清什么方法应该private/什么方法应该public的程序员,也会害怕写单元测试:不知道应该在哪切这一刀来看问题。

    作者回复: 是的,良好的设计会让测试更好写。

    2019-03-01
    1
  • Nemo
    能不能手把手教一下如何写一个完整,优秀的单元测试?

    作者回复: 好建议,我可以考虑加餐。

    2019-02-13
    1
  • 玄源
    实际情况是:很多时候,项目时间很紧,经常会提测后,再补,或者直接code review,测试就不写了;

    作者回复: 项目永远很紧,时间永远不够,你打算永远这样吗?

    2019-02-01
    1
  • 巫山老妖
    测试没有银弹,主要看大家对测试这件事情的认知是否一致,现在都在推崇测试左移,尽可能玩发现问题,这就对程序员提出更高的要求。

    作者回复: 优秀程序员总是少数的,会写测试就已经上了一级台阶,能在写代码之前思考测试,就会再上一级台阶。

    2019-01-27
    1
  • 肉墩儿快跑
    看绩效了,只要价钱足够高,就能保证了

    作者回复: 经济学告诉我们,没有足够高的价钱。

    2019-01-26
    1
  • 草原上的奔跑
    作为一个程序员,怎么保证自己写出来的程序是好的,答案是写测试,只有自己通过了单元测试、集成测试、系统测试,那么提测的时候我们才会有底气,而不是时刻准备着测试出问题去改。但是,很不幸的是,团队内部成员没有写测试的意识,让他们写,以不会写、时间不够为借口,就是不写,不知道郑老师对这种情况有没有好的解决办法。

    作者回复: 很多不喜欢写测试的真实原因是,不会写。他们先要知道写测试是怎么回事,可以把我这个系列学完之后,分享给他们。

    2019-01-26
    1
  • 刘冲
    老师,集成测试是谁来写?测试人员么
    2019-06-26
  • 鱼蛋粉
    自从知道测试人员的测试只是基于界面的点点点,之后写的每个方法都必需写单元测试。写单元测试是对自己负责。

    作者回复: 呃,这个角度好神奇,但你意识到要多写测试就好。

    2019-04-27
  • enjoylearning
    测试会提高我们的设计能力,写出clean code

    作者回复: 想写好测试,要写好代码。

    2019-03-28
  • 苦行僧
    单元测试不好写 基本可以断定业务代码和通用代码纠结在一起了 需要重构

    作者回复: 耦合是肯定的

    2019-03-11
收起评论
22
返回
顶部