1. google 测试分层理论

谷歌三篇论文 Google File System、Google Bigtable、Google MapReduce 引领了大数据整个领域。
Google 软件测试之道 引领了软件测试行业。
测试金字塔，测试分层是这本书两个基本的理论（图片截取自书中）：

书中大部分总结都来自谷歌在 2010 年前后谷歌的实践，参考https://testing.googleblog.com/
现在是 2020-07-12，云原生的基础设施和编排能力已经成为企业的标配，结合书中的理论，我们需要重新思考具体业务实践。

2. 单元测试依赖数据库

单元测试要尽量的减少依赖，其中包括对数据库的依赖。表 2.2 中小型测试中推荐使用 Mock 的方式来进行数据库相关的测试。
为什么要减少对外界的依赖？
因为依赖会带来：
依赖构建成本高，不确定性，不稳定性，耗时高等因素，这些因素对小型测试是有害的。

在微服务和代码结构分层的前提下（存储服务 || DAO 层），存储层代码如何进行单元测试呢？
他们通常采用内存数据库作为单元测试数据库，如：H2

步骤：

• 配置针对单元测试的数据源 mybatis_config_h2_test.xml

  <!-- h2测试库配置 -->
  <environment id="pre">
    <transactionManager type="JDBC"/>
    <dataSource type="POOLED">
      <property name="driver" value="org.h2.Driver"/>
      <property name="url" value="jdbc:h2:mem:test;INIT=runscript from nit.sql'\;"/>
      <property name="username" value=""/>
      <property name="password" value=""/>
      <property name="poolPingEnabled" value="true"/>
      <property name="poolPingQuery" value="SELECT 1+1"/>
      <property name="poolPingConnectionsNotUsedFor" value="0"/>
      <property name="poolMaximumActiveConnections" value="150"/>
      <property name="poolMaximumIdleConnections" value="150"/>
      <property name="poolMaximumCheckoutTime" value="20000"/>
      <property name="poolTimeToWait" value="20000"/>
    </dataSource>
  </environment>
</environments>

• 单元测试过程中 load 数据源

• 进行单元测试
  使用内存数据库模拟实际数据库有以下几个问题：

• 内存数据库无法完全模拟实际数据库的能力，MySQL 、Oracle...

• 对于一不支持的情况需要进行适配

• 内存数据库测试通过不能完全认为在实际数据库中没问题

• 开发同学需要学习 h2 数据库的一些坑，如何规避
  灵魂的拷问：
  为什么用这么大精力构建 “假的” 内存数据库，直接安装 MySQL 不可以吗？

3. 云原生和 DevOps

这 10 年我们经历了什么？

• 机器配置： 2010 年公司配置的开发机是 8G 内存，终端开发为了加快编译配置 16G 2020 年 32G 内存开发机是标配，另外还配置了研发域 DevCloud 机器 电脑里把 MySQL、Redis、MongoDB....都安装启动也没什么压力。
• 技术的发展 云原生：基础设施不可变性，利用 docker、镜像能力可以快速构 MySQL，Redis 等依赖 DevOps：将团队的基础设施和流程固化

我们有条件快速、低成本、便捷的构建环境

我们的方案：
抛弃内存数据库，单元测试直接依赖 MySQL、Redis 等数据基础设施
以依赖 MySQL 数据库的单元测试为例：

• 单元测试直接依赖本地 MySQL 数据库
• 制作团队基础开发镜像，安装 MySQL 数据
• 团队成员根据自身开发需求编写数据库脚本
• DevOps 流程中依赖相同的基础镜像，在基础镜像之上增加编译相关层次

收益：

• 团队不需要再为 H2 数据库的坑努力
• 本地调试更加方便
• 开发环境、编译环境、真实环境（测试、线上）依赖一致，测试更加有效

4. 思考

4.1 复杂度来源

程序要解决的是业务复杂度问题，微服务技术并没有降低业务复杂度，甚至因为微服务之间的依赖提高了复杂度。
真正的业务并不会像迭代 0 中代码编写的那样纯粹，按照文件夹区分单元测试、模块间测试、接口测试。复杂度使得我们在做金字塔底层测试时需要进行很多 Mock

过早进行集成测试测试的成本会很高

4.2 云原生体系下该如何做测试

• 我们测试对象，后台服务开始云化，云化后该怎么测试？
• 借助云原生的能力，构建测试基础设施，测试云化后会有什么样的变化？

本文不是挑战测试分层和测试金字塔理论，主要是通过在项目中的一些实践，引发一些思考，欢迎拍砖，一起讨论