单元测试用例设计方法

单元测试的意义

  • 提高代码质量
  • 尽早发现问题: 问题发现的越早,解决问题的成本越低
  • 保证重构正确性: 随着功能的增加,重构几乎不可避免。很多时候我们不敢重构的原因就是担心其他模块因为依赖它而不工作。有了单元测试,只要在改完代码后运行一下单测就知道改动对整个系统影响了,从而可以让我们放心的重构代码
  • 简化调试过程: 单元测试让我们可以轻松的知道是哪一部分出了问题
  • 简化集成过程: 由于各个单元已经被测试,在集成过程中进行后续的测试会更容易
  • 优化代码设计: 编写测试用例会迫使开发人员仔细思考代码的设计和必须完成的工作,有利于开发人员加深对代码功能的理解,从而形成更合理的设计和结构
  • 单元测试就是最好的文档: 单元测试覆盖了接口的所有使用方法,是最好的示例代码。而真正的文档包括注释很有可能和代码不同步,并且看不懂

go test - 基准测试

series:

稳定的测试环境

性能测试受环境影响很大,为保证测试的可重复性,尽可能地保持测试环境的稳定

  • 机器处于闲置状态,测试时不要执行其他任务,也不要和其他人共享硬件资源
  • 机器是否关闭了节能模式,一般笔记本会默认打开这个模式,测试时关闭
  • 避免使用虚拟机和云主机进行测试,虚拟机和云主机 CPU 和内存一般会超分配,性能表现会非常地不稳定

go test - 单元测试

series:

go test 常见做单测试、基准测试和 http 测试

go test 还有很多 flag 可以帮助我们做更多的分析,比如测试覆盖率,cpu 分析,内存分析,也有很多第三方的库支持 test,cpu 和内存分析输出结果要配合 pprof 和 go-torch 来进行可视化显示

github 一些缩写

缩写 解释
PR(Pull Request) 给其他项目提交代码
LGTM(Looks Good To Me) 朕知道了 代码已经过 review,可以合并
SGTM(Sounds Good To Me) 和上面那句意思差不多,也是已经通过了 review 的意思
WIP(Work In Progress) 传说中提 PR 的最佳实践是
如果你有个改动很大的 PR,可以在写了一部分的情况下先提交
但是在标题里写上 WIP,以告诉项目维护者这个功能还未完成,方便维护者提前 review 部分提交的代码
PTAL(Please Take A Look) 你来瞅瞅?用来提示别人来看一下
TBR(To Be Reviewed) 提示维护者进行 review
TL;DR(Too Long; Didn’t Read) 太长懒得看。也有很多文档在做简略描述之前会写这么一句
TBD(To Be Done/Defined/Discussed/Decided/Determined) 根据语境不同意义有所区别,但一般都是还没搞定的意思

cgi考古

工作至今还未亲自写过 cgi,今天考个古

五笔

花儿五笔用了多年,我找到的第一个能满足能设置成重码词才弹候选框,其他时候完全隐藏,直出字的输入法

主打一个打字时不要候选框来干扰我注意力

手机上也五笔

之前是极点五笔