互联网业务中单元测试

前言

文中将从测试对象、敏捷、优先级三个维度介绍互联网业务为何单测较难落地；根由为产出比、时间成本。同时，提出可以实践场景；推荐参考文末链接进行深层学习

被测对象

互联网业务中 被测对象 包括：
       前端代码：
            js
            css
            图片
            html
       服务端：
            代码     ---单测命中
            数据库  ---业务在数据层
            缓存
            消息队列
            开关    ---开关组合
       底层基础服务：
            容器
            中间件
            基础软件配置
       网络层

单测对象为代码，能保证代码、逻辑正确；是传统软件测试重要组成。

单测实践只保证代码正确性，不能保证数据正确性。互联网某些业务，从代码角度看逻辑简单，增删改查；是由数据库中多张表组成复杂业务，单元测试对数据层覆盖不全，造成业务漏测。

在互联网业务中，开关组合会大量应用，从而实现复杂逻辑，但单测也不会触及某些开关测试。

最后，单测测试范围窄，仅仅代码；而整个系统由 前端、服务、底层、网络共同配合运行；由此见 单测 仅是质量保障体系中一个维度，且保障范围有限，落地有些困难。但大多测试人员为提高代码能力，乐于从事单测、自动化事务

实践敏捷

随着敏捷实践，以及微服务引入；软件产品中代码特性也有了很大变化

          代码周期         ---快抛型：开发、上线、重构 周期短（< 1 year）
          代码逻辑简单  ---微服务化加剧，代码自动生成 mapper
          单测收益有限  ---维护成本高，迭代快，时间成本
                                     CRUD逻辑和日志，异常处理

工作优先级

比单测更重要事情
          合理应用架构               ---不合理引发问题、bug可以放大
          接入监控，接入灰度    ---运维
          业务快速交付               ---这个业务能否存活，快速交付
          用户高优先级问题        ---oncall，快速定位处理 代码问题、性能问题、集群问题 等等 处理问题重要性高于单测

以上是来不及不进行单测客观原因；但某些场景可以单测：

单测可实践场景

单测@部分业务：
          金融类底层业务
          质量要求高核心部件  ---大量调用
          黑盒方式难测试、难覆盖的业务
          复杂计算类业务
          业务不忙团队

参考资料：

单元测试为什么在互联网滑铁卢