读程序员的README笔记07_测试(下)

这篇具有很好参考价值的文章主要介绍了读程序员的README笔记07_测试(下)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

读程序员的README笔记07_测试(下)文章来源地址https://www.toymoban.com/news/detail-750399.html

1. 自己动手编写测试

1.1. QA团队可以帮助你验证你的代码是否稳定,但千万不要把代码直接丢给他们,然后让他们做所有的测试

1.2. 避免硬编码的值,不要重复代码

1.3. 专注于测试基本功能而不是实现细节,这有助于代码库的重构

1.3.1. 测试代码在重构后仍然可以运行

1.4. 将测试的依赖项与常规代码的依赖项分开

2. 避免过度测试

2.1. 要编写那些在测试失败的时候有意义的测试,不要为了提高代码覆盖率而去提高代码覆盖率

2.1.1. 测试数据库包装器、第三方类库或基本的变量赋值,即使它们能提高覆盖率指标,也是毫无价值的

2.1.2. 要专注于那些对代码风险有最大影响的测试

2.2. 将代码覆盖率作为一个指南,而不是硬性的规则

2.2.1. 高的代码覆盖率并不能保证正确性

2.3. 不要为自动生成的代码手动编写测试

2.3.1. Web框架

2.3.2. 脚手架

2.3.3. OpenAPI客户端

2.4. 代码生成器是经过彻底测试的,所以测试自动生成的代码是在浪费时间

2.4.1. 除非你手动引入对生成文件的修改,在这种情况下,你应该测试它们

2.5. 把精力集中在最高价值的测试上

2.5.1. 测试需要时间来编写和维护

2.5.2. 专注于高价值的测试,可以产生最大的收益

2.5.2.1. 首先应该关注代码中的高风险的区域

2.5.2.2. 那些低风险或被废弃的代码并不值得测试

3. 测试中的确定性

3.1. 确定性的代码对于相同的输入总是给予相同的输出

3.2. 非确定性的代码对于相同的输入可以返回不同的结果

3.2.1. 一个需要在网络套接字上调用远程网络服务的单元测试具有不确定性

3.2.1.1. 如果网络出现问题,那么测试也会失败

3.2.2. 测试中的不确定性降低了测试的价值

3.3. 间歇性的测试失败(被称为拍打测试)是很难重现和调试的

3.3.1. 它们不会在每次运行时都复现

3.3.2. 你不知道问题是出在测试本身还是你的代码上

3.3.3. 拍打测试的结果不能提供有意义的信息,开发人员可能会忽略它们,并因此提交错误的代码

3.3.4. 间歇性失败的测试应该被禁用或立即修复

3.4. 非确定性通常是由对休眠、超时和生成随机数的不恰当处理引入的

3.4.1. 测试中遗留下来的副作用或与远程系统交互也会导致非确定性

3.5. 种子随机数生成器

3.5.1. 随机数生成器(random number generators,RNG)必须使用一个值作为种子,这个值决定了你从它那里获取的随机数

3.5.2. 可用一个常数作为随机数生成器的种子,迫使它每次运行时都能确定地生成相同的序列

3.5.2.1. 使用常数种子的随机数生成器的测试将总是通过或总是失败

3.6. 不要在单元测试中调用远程系统

3.6.1. 远程系统的调用需要网络跳转,这是不稳定的

3.6.2. 避免远程调用也能保持单元测试的快捷和可移植性

3.6.3. 通过使用模拟库或重构代码来剔除单元测试中的远程系统调用,从而使远程系统仅在集成测试中被需要

3.7. 采用注入式时间戳

3.7.1. 如果处理不当,依赖于特定时间间隔的代码会导致非确定性

3.7.2. 使用静态的系统时钟方法,如now或sleep,则表明你的代码依赖于时间

3.7.3. 可以使用注入式时间戳而不是静态时间方法,这样你就可以控制你的代码在测试中获取的时间

3.7.3.1. 注入式时间戳将让你使用模拟来精确控制测试中的时间流逝

3.8. 避免使用休眠和超时

3.9. 记得关闭网络套接字和文件句柄

3.9.1. 许多测试都会泄露操作系统的资源,因为开发人员认为测试是短暂的,当测试终止时,操作系统自己会清理一切

3.9.2. 泄露的资源会导致不确定性

3.9.3. 操作系统对打开的套接字和文件句柄的数量有一个上限,当有太多的资源被泄露时,操作系统就会开始拒绝新的请求

3.10. 绑定到0端口

3.10.1. 测试不应该绑定到某个特定的网络端口

3.10.2. 绑定静态端口会导致不确定性

3.10.2.1. 在一台计算机上运行良好的测试在另一台计算机上会失败,只是因为端口被占用了

3.10.3. 将所有测试都绑定到同一端口是一种常见的做法

3.10.3.1. 这些测试在串行时会运转良好,但是在并行时就会失败

3.10.3.2. 测试失败将是不确定的,因为测试并不总以相同的顺序执行

3.10.4. 将网络套接字都绑定到0端口,这将使操作系统需要自动去选择一个开放的端口

3.10.4.1. 测试可以检索被选中的端口,并在该项测试的剩余部分使用这个端口

3.11. 生成唯一的文件路径和数据库位置

3.11.1. 测试不应该写入某一个已经被静态定义好了的位置

3.11.2. 数据的持久性与网络端口绑定有同样的困境

3.11.3. 恒定的文件路径和数据库位置会导致测试之间相互干扰

3.11.4. 应该动态地生成唯一的文件名、目录路径以及数据库或表名

3.11.4.1. 动态ID可以让测试并行执行,因为它们都会读写到各自的位置

3.12. 隔离并清理剩余的测试状态

3.12.1. 不清理测试状态会导致不确定性

3.12.2. 无论你的测试是否通过,你都必须重置状态,不要让失败的测试“留下残渣”

3.13. 不要依赖测试顺序

3.13.1. 测试不应该依赖于特定的执行顺序

3.13.2. 在每次运行之间重置状态,将防止测试在状态发生突变时相互破坏

到了这里,关于读程序员的README笔记07_测试(下)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 读程序员的README笔记10_软件交付(上)

    3.1.1.1. 打包一个构件称为发布 3.1.3.1. 部署的软件还不能被用户访问 3.1.3.1.1. 只是被安装了而已 3.1.3.2. 一旦部署,软件就会通过将用户转移到新的软件上而进行展开 3.1.4.1. 交付过程是更大的产品开发周期中的一部分 6.10.2.1. 每季度或每年发布一次

    2024年02月04日
    浏览(160)
  • 读程序员的README笔记01_学习如何学习

    6.3.2.1. 错误是不可避免的。成为一名软件工程师的路途艰辛,我们有时会失败 6.5.4.1. 代码从不说谎。注释有时却会。 6.5.4.1.1. Code never lies. Comments sometimes do 6.5.4.1.2. 去读源代码,因为它并不总是与设计文档相吻合 6.5.4.1.3. 不要只读你自己的代码库,还要去阅读高质量的开

    2024年02月05日
    浏览(54)
  • 读程序员的README笔记11_软件交付(下)

    1.3.5.1. 通过持续交付,人力被完全从部署环节中移除 1.3.5.2. 打包、测试、发布、部署,甚至展开环节都是自动化的 1.3.6.1. Puppet、Salt、Ansible和Terraform等现成的解决方案可以与现有的工具集成,并且它们是专门为了自动化部署而设计的 1.4.4.1. 只需再次指向旧的版本 1.5.1.1. 

    2024年02月04日
    浏览(61)
  • 读程序员的README笔记04_防御式编程

    1.2.1.1. 切记让你的代码安全而有弹性 1.2.1.2. 编写拥有良好防御性的代码是一种对那些运行你的代码的人(包括你自己!)富有同情心的表现 1.2.1.3. 防御性的代码较少发生故障,就算它发生故障,也更有可能恢复 1.2.1.4. 安全的代码利用编译时的校验来避免运行时的故障,使

    2024年02月05日
    浏览(60)
  • 读程序员的README笔记14_技术设计流程(下)

    1.4.2.1. 该项目将需要至少一个月的工程时间 1.4.2.2. 变更将对软件的扩展和维护产生长期的影响 1.4.2.3. 变更将显著影响其他团队 1.5.2.1. 设计文档是一种工具,可以帮助你思考、获得反馈、让你的团队了解情况、培养新的工程师,并推动项目规划 1.5.5.1. 阅读大量的设计文档

    2024年02月04日
    浏览(44)
  • 读程序员的README笔记18_职业生涯规划

    3.1.5.1. 他们的工作职责之一是管理他们的团队,而管理的一部分就是对你投入时间 3.1.5.2. 对管理者而言,反复取消一对一面谈可以是一个有价值的信号 3.3.2.1. 每个目标都附有3到5个关键结果,它们是标志着目标达成的具体指标 3.3.2.2. 不要把关键结果变成待办事项清单 3.

    2024年02月04日
    浏览(55)
  • 读程序员的README笔记05_日志、监控与配置

    6.1.1.1. 测量的是某个事件发生的次数 6.1.1.2. 通过使用计数器获得缓存命中数和请求总数,你就可以计算出缓存命中率 6.1.2.1. 一个基于时间点的测量值 6.1.2.2. 既可以上升又可以下降 6.1.3.1. 根据事件的大小幅度分成不同的范围 6.1.3.2. 每一个范围都会有一个计数器,每当某

    2024年02月05日
    浏览(54)
  • 读程序员的README笔记13_技术设计流程(上)

    3.4.1.1. 外界干扰是深度工作的“杀手” 3.4.1.2. 避免所有的交流方式 3.4.1.2.1. 关闭聊天 3.4.1.2.2. 关闭电子邮件 3.4.1.2.3. 禁用电话通知 3.4.1.2.4. 换个地方坐 3.4.2.1. 有形产出是一份设计文档 4.2.3.1. 如果有一个以上的问题,询问哪些问题是最优先的 4.3.7.1. 注意与外人交流时不

    2024年02月04日
    浏览(71)
  • 读程序员的README笔记12_On-Call

    4.4.2.1. 回应不一定代表解决方案 4.4.3.1. 每次更新时,提供一个新的时间预估 4.5.3.1. 如果请求者没有回应,就说你将在24小时内因缺乏回应而关闭该任务票,然后真的这样做 5.3.1.1. 工程师必须找到问题,确定其严重性,并确定谁能修复它 5.3.1.2. 确认问题并了解其影响,以

    2024年02月04日
    浏览(44)
  • 读程序员的README笔记17_构建可演进的架构(下)

    1.3.3.1. 开发人员可以只专注于和自己相关的字段,因为它们会继承其他字段的默认值 1.3.3.2. 默认值可使大型API在感觉上很小巧 1.4.1.1. OpenAPI通常用于RESTful服务 1.4.1.2. non-REST服务则使用Protocol Buffers、Thrift或类似的接口定义语言(interface definition language,IDL) 1.4.1.3. 接口定义工

    2024年02月04日
    浏览(57)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包