大型的软件工程项目除了大量的产品级代码外必不可少的还有大量的自动化测试。自动化测试包含从前端到后端甚至到产品线上不同模块和环境的各种类型的测试。一个比较经典的关于自动化测试分布的理论就是测试金字塔，是说在一个正常的项目中合理的测试数量应该是单元测试 > 组件测试 > 集成测试 > 端到端测试（系统测试）> 人工验证测试。这个理论大体上是合理的，因为从测试代码的复杂度和执行时间看单元测试 < 组件测试 < 集成测试 < 端到端测试（系统测试）< 人工验证测试，所以我们理所当然应该分配更多的时间和精力到容易理解和执行快速的测试中去，比如单元测试。当然关于这些测试分类和界定的看法众说纷纭，比如组件测试和集成测试，有时甚至是端到端测试，都一概被称为集成测试，因为它们在不同的系统层面试图去测试两个模块或者系统间的集成状况。

最经典的集成测试的例子应该是后端系统应用层和数据层之间的集成测试了吧。数据层可以是传统的数据库，也可以是Kafka Stream这样的新宠。通常这种集成测试有几种思路：

部署到staging环境中，然后在测试中发送请求到系统A，那个请求会包含对数据层系统B的读写操作。这个其实算是跳过集成测试到了端到端测试。但这种思路弊端很多，测试代码复杂度高，路径覆盖率低，从写出bug到检测到bug的周期也很长，不是理想的解决方案。
在测试中使用In-memory Embedded Database(通常是实际数据库系统B的纯内存化实现版本，主要用于这种测试环境里)，这样就能细化到测试系统A里面模块X对数据库B的某个写操作，而且可以在本地编写、运行、调试，和上面的解决方案比已经有了很大的改进。但是这个解决方案还是有几个弊端：

很多In-memory Embedded Database只提供一个特定版本的实现，比如MongoDB 3.2，但如果你的实际数据库版本是4.0，那么很多新的数据库功能在测试里根本覆盖不了。
有些In-memory Embedded Database甚至没有实现100%的接口兼容，或者不一样的实现方式，比如关系型数据库的transaction实现。这意为着就算你的测试过了，线上的代码还是可能会出错。这是常见的生产环境和测试环境不一致性问题。

受益于Docker的普及化，testcontainers提供了另外一种更为友好的集成测试解决方案。简单地讲就是在测试环境中动态创建需要的依赖服务的容器，比如动态创建一个Mongo 3.6的容器、创建一个RabbitMQ 最新发布版的容器，然后在测试中配置测试环境让测试应用使用创建好的容器暴露的可调用地址，测试结束后把使用过的容器销毁防止依赖服务状态迁移导致其他的测试莫名地挂掉。

这种解决方案有以下几个优点：

每个Test Group都能像写单元测试那样细粒度地写集成测试，保证每个集成单元的高测试覆盖率
Test Group间是做到依赖隔离的，也就是说它们不共享任何一个Docker容器；假如两个Test Group都要用到Mongo 4.0，会创建两个容器供它们单独使用
保证了生产环境和测试环境的一致性，代码部署到线上时不会遇到因为依赖服务接口不兼容而导致的bug
Test Group可以并行化运行，减少整体测试运行时间。相比较有些in-memory 的依赖服务实现没有实现很好的资源隔离，比如端口，一旦并行化运行就会出现端口冲突。
得益于Docker，所有测试都可以在本地环境和CI/CD环境中运行，测试代码调试和编写就如同写单元测试

当然，它也有几个劣势：

测试运行时间长：因为每个Test Group需要动态创建和销毁Docker容器，这两个步骤很多时候占用了大部分测试运行时间。当然客观地讲，这个等待时间还是秒级别的，所以还是能接受的。如果你再并行运行测试，总体运行时间还是可控的。
测试编写、调试体验因为上面一点而受到影响
资源占用率高：大部分的build agent都是一个虚拟机，甚至是一个docker进程，再加上还要给每个Test Group分配资源跑它们的依赖服务，整个build agent的CPU、内存使用率都会增加不少。在繁忙的时候甚至出现性能退化问题。解决方法就是scale up/out build agent。

从编程语言支持度来说，目前testcotainers的github org上提供了Java, Scala, Go, Rust, NodeJs, Python, C#的类库。从成熟度来说肯定是Java的类库最为成熟，已被不少开源项目使用。其他语言的类库可以想象不可避免会有些坑需要踩。

举一个官网的例子来说明如何使用testcontainers类库：

public class RedisBackedCacheIntTest {

    private RedisBackedCache underTest;

    // rule {
    @Rule
    public GenericContainer redis = new GenericContainer<>("redis:5.0.3-alpine")
                                            .withExposedPorts(6379);
    // }


    @Before
    public void setUp() {
        String address = redis.getContainerIpAddress();
        Integer port = redis.getFirstMappedPort();

        // Now we have an address and port for Redis, no matter where it is running
        underTest = new RedisBackedCache(address, port);
    }

    @Test
    public void testSimplePutAndGet() {
        underTest.put("test", "example");

        String retrieved = underTest.get("test");
        assertEquals("example", retrieved);
    }
}

上面的JUnit测试中动态创建了一个redis:5.0.3-alphine容器，在setUp方法里获取该容器的公开地址和接口从而创建我们要测试的RedisBackedCache实例，然后在测试里轻轻松地调用该实例的方法、验证结果。

testcontainers Java 提供了几个现成的使用频率较高的容器的类封装，比如大部分数据库(MySQL, Postgres, Cassandra, Neo4j), UI测试的Webdriver，ElasticSearch，Kafka, Nginx等等。如果你没找到现成的封装，你总是可以调用更底层的`GenericContainer`。它也支持主流的Java测试框架，JUnit4, JUnit 5, TestNG，Spock。总的来说对于写Java的同学这个类库使用起来还是非常爽的！

看了这么多，你是不是也心动了呢?! 那就快快行动起来吧，常言道：会哭的孩子有奶吃，会写测试的开发有饭吃！

2019.4.14

本文原载于: 【技术博客】基于testcontainers的现代化集成测试进阶之路

----------------------------------------------------------------------------------------

艺与术公众号(various__artists): 分享关于编程、软件工程、系统架构、前沿技术的艺与术的思考。