科技壹零扒|再读《重构》( 三 )
有一些关于测试的建议会推荐我们测试所有可能的组合 ， 虽然这些建议值得了解 ， 但是实践中我们需要适可而止 ， 因为测试达到一定程度之后 ， 其边际效用会递减 。 如果编写太多测试 ， 我们可能因为工作量太大而气馁 。 我们应该把注意力集中在最容易出错和最没有信心的地方 。
一些测试的指标 ， 如覆盖率 ， 能一定程度上衡量测试是否全面而有效 ， 但是最佳的衡量方式可能来自于主观的感受 ， 如果我们觉得对代码比较有信心 ， 那就说明我们的测试做的不错了 。
文章图片
不依赖于某个特定测试框架进行测试
在老马的测试例子中 ， 用到了mocha和chai两个JavaScript的测试工具 ， 恰好这两个框架也是我写JS代码时最喜欢用的工具 ， 除此之外 ， 还有一个用来模拟对象的库sinon 。 这三个工具是大概两年前我从我们的QA处得知的 ， 用起来十分趁手 ， 一直沿用到现在 。
这三个工具的一大特点就是不依赖任何其他框架而独立存在 ， 属于那种小而美的工具 。 这里我想提这三个工具的原因是我经常发现不少同学喜欢使用某个框架自带的测试基础设施进行测试 ， 而非使用这些小而美的工具 。 比如很多人喜欢使用Angular提供的TestBed进行测试 ， 或者喜欢使用Spring提供的SpringBootTest注解进行测试 。 然而这样测试的问题在于其过度依赖于某个框架 ， 测试运行过程中会执行到大量的框架代码 ， 从而导致测试运行缓慢 ， 出错了也不好定位问题 。 事实上我们的代码中主要关注的是应用自身的业务逻辑 ， 这些业务逻辑才是测试的重点 ， 而非框架的逻辑 。 当然有时候我们可能对框架的配置代码信心不够强（比如spring的配置还是比较复杂的） ， 这个时候 ， 我们可以有针对性的写少数几个测试来验证这些配置就足够了 。 对于应用自身的业务逻辑代码的测试 ， 完全没必要基于某个具体框架来做 ， 试想如果这些测试都是仅仅基于junit实现的 ， 那这些测试将非常容易理解 ， 非常容易迁移（比如当前的一个基于Spring的后端项目 ， 可以根据需要很容易的迁移到Android移动平台） 。
基于工具而非某个特定框架去组织测试的实践使我在平常工作中获益良多 ， 而基于某个特定框架实现的测试往往维护困难 。 有了这样的认识 ， 我们再来看本书中的所有测试 ， 我们将发现它们都是简单而有效的 。
（严格来说 ， mocha或者junit应该也算一种测试框架 ， 但是他们的好处在于非常轻量 ， 没有任何其他框架的依赖和束缚 。 在这里我想表达的是我们要弱化某个具体的框架 ， 转而使用一些通用框架和工具进行测试 。 ）
最后
当然书中的精华还有很多很多 ， 我尤其喜欢前四章以及后续重构名录中的动机部分 ， 这些部分详细的回答了“为什么做”以及“何时做”这两个问题 。 总之 ， 本书值得当做一本程序员字典时常翻阅 。
文/ThoughtWorks廖光明
推荐阅读
- 三星公司发布2021款数字座舱 集成诸多高科技
- 刚有望“出人头地”就被三大科技巨头围剿，“挺川者”新阵地下线
- 谷歌建立新AI系统 可开发甜品配方
- 柔性电子市场广阔，领头羊柔宇科技获更多关注
- 曝LG也将推出卷轴屏手机 你怎么看？
- AI战疫、真5G来了，十大最热门科技应用演绎速度与温度
- 又爆炸！联电科技传来一声巨响，或把8 英寸晶圆市场"炸"了
- 唐山四维智能科技有限公司：双臂机器人引领人机协作新纪元
- 国家超算郑州中心首批重大科技专项启动
- 青岛海科展：五年磨一剑，科技力量助力海洋强国