10x 程序员工作法
郑晔
开源项目 Moco 作者
53432 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 63 讲
思考框架 (1讲)
10x 程序员工作法
15
15
1.0x
00:00/00:00
登录|注册

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

XUnit
JUnit
单元测试
测试数量
金字塔模型
蛋卷模型
测试框架
持续集成
测试模型
自动化测试
开发者测试
写好代码和测试
代码提交前的基本功能测试
外部功能特性测试
程序员
测试人员
测试
测试也是程序员的事吗?

该思维导图由 AI 生成,仅供参考

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

谁要做测试?

你是一个程序员,你当然知道为什么要测试,因为是我们开发的软件,我们得尽可能地保证它是对的,毕竟最基本的职业素养是要有的。
但测试工作应该谁来做,这是一个很有趣的话题。很多人凭直觉想到的答案是,测试不就该是测试人员的事吗,这还用问?
测试人员应该做测试,这是没错的,但是测试只是测试人员的事吗?
事实上,作为程序员,你多半已经做了很多测试工作。比如,在提交代码之前,你肯定会把代码跑一遍,保证提交的基本功能是正确的,这就是最基本的测试。但通常,你并不把它当成测试,所以,你的直觉里面,测试是测试人员的事。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

软件开发中的测试工作至关重要,程序员应该参与其中并通过自动化测试来提高软件质量。测试框架的出现标志着测试自动化成为了一种最佳实践,而测试金字塔模型则强调越底层的测试应该写得越多。持续集成与测试金字塔模型天然配合,底层测试的数量决定着得到反馈的早晚。因此,程序员在软件开发中应该重视测试工作,尤其是多写单元测试。通过理解不同层次测试的差异,团队可以更好地组合不同类型的测试,提高软件质量。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《10x 程序员工作法》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(43)

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

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

    2019-01-25
    3
    71
  • difoil
    能不能手把手教一下如何写一个完整,优秀的单元测试?

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

    2019-02-13
    2
    41
  • jacky
    团队认知,开发周期,软件和生命财产关系不大,是单元测试的拦路虎

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

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

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

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

    作者回复: 1和2,本质上是一个问题。其实,很多人担心写测试会影响写代码,但实际上,写测试,尤其是单元会帮助写代码,否则,你用的手工测试或系统测试的方式来保证系统的正确性。如果你不花练习写测试,你永远学不会写测试,写测试在你看来就是浪费时间。 这背后其实还隐藏着另外一个问题,为什么会变化快?因为一方面,前期的工作做得少,这是我们前面讲的内容要解决的,另一方面,设计做的不好,变化都是大变化,设计不做好,那就到处是问题,这是我们后面要讲的内容。 3,国内公司在工程上做得都不够好,如果想看好榜样,可以看看国外的公司,比如,Google,它要求100%测试覆盖率。

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

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

    2019-01-25
    12
  • 学习
    非常认同之前听到的一句话,单元测试不是为公司写的,而是为自己写的。 在公司都不写单元测试的情况,你写了,差距就产生了,你进步得越快,就能越早脱离不好的公司,至少我认为,单元测试都不愿意写的公司绝对不是好公司

    作者回复: 为自己写测试,好棒!

    2021-12-16
    9
  • 🌲树根🌲
    我的想法可以在复杂度高,重要核心的模块先开始写单元测试。特别是公用、底层的,因为这些靠功能测试很难覆盖。 单元测试难以推行主要是没有碰到质量的痛点,通常都依靠测试工程师来保证质量。我们之前就在遇到过质量崩塌,倒逼着我们去做,以保证质量。

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

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

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

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

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

    2019-01-30
    2
    6
收起评论
显示
设置
留言
43
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部