Banner

学习性测试（Learning Tests）[1]最早由Jim Newkirk在Test-Driven Development in Microsoft .NET一书中提及，用以表述在对第三方接口或资源包学习的过程中，通过本地编写测试来遍历我们需要用到的功能，并以此作为后续自身项目质量保证一环的软件编程行为。

在我们自身的软件编写实践中，相信大家都或多或少的采用了这种模式：遇到困难或需求，现代软件开发方式通常是第一时间通过搜索的方式寻找可用的API或开源库依赖，将其集成到我们自己的软件资源库之后，阅读相关接口文档，编写一些main方法对齐进行校验，或者直接使用postman等工具直接对开放API进行验证，这在一定程度上可以保证我们编码的正确性。但如果在这个的基础上更进一步，将测试的过程实例化、系统化，便是我今天要同大家一起探索的学习性测试。

1. 项目选择与环境搭建

在这里，我选择了Java实体映射工具MapStruct [2]作为学习性测试对象，在代码编写的过程中，我经常会遇到从一个类型的实体向另一个结构相似的实体转换的工作，这可能是从DTO向VO的转换，也可能是从ReqeustParam向Model的参数设置，anyway，在这个场景下我选择不去自己实现复杂的ConvertUtils来完成转换逻辑，而是转而向已有的第三方工具MapStruct求助。通过阅读MapStruct的官网，我了解了通过maven或gradle直接添加依赖的方式就能将MapStruct集成到我的SOFA应用中。同时，我选择通过JUnit来完成我的单元测试，至此，一套简单并且完整的学习性测试框架就搭建好了。

2.第一行测试

按照最小功能测试原则，我们从一个最简单的源到目标转换为例对MapStruct的用法进行测试，这里我们在测试代码包中添加转换源类：

public class TestSource {
}

和转换后的目标类：

public class TestTarget {
}

以及MapStruct转换器接口类：

@Mapper
public interface TestMapper {
    TestMapper INSTANCE = Mappers.getMapper(TestMapper.class);

    TestTarget source2target(TestSource source);
}

然后通过一个最简单的测试来验证转换是否能够执行：

    @Test
    public void should_return_not_null_target_when_convert() {
        TestSource source = new TestSource();
        TestTarget target = TestMapper.INSTANCE.source2target(source);
        Assert.assertNotNull(target);
    }

但结果很不巧，提示找不到接口TestMapper的实现。

Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: Cannot find implementation for com.example.blog.TestMapper
	at org.mapstruct.factory.Mappers.getMapper(Mappers.java:79)

这很好：）测试用例失败了，我们换上红帽子去寻找原因。通过阅读MapStruct相关文档，我们了解到转换器接口实现是在构建期完成的。这里我们对测试模块进行重新清理并构建后，测试用例正式通过。

3.逐渐深入

3.1简单的值映射

那么如果我的源目标转换的过程中，需要对整型和字符串进行转换，MapStruct是否能支持呢？带着这样的疑问，我对代码进行了如下的修改：

public class TestSource {
    private int integer;
    private String str;
//setter and getter
}

public class TestTarget {
    private int integer;
    private String str;
//setter and getter
}

@Test
    public void should_map_field_value_correct() {
        TestSource source = new TestSource();
        source.setInteger(1);
        source.setStr("str");

        TestTarget target = TestMapper.INSTANCE.source2target(source);

        Assert.assertEquals(1, target.getInteger());
        Assert.assertEquals("str", target.getStr());
    }

这里如果你直接执行新修改的测试，相信我，一定会失败。因为我们通过刚才的测试性学习了解到，接口的实现是在构建期根据源与目标的关系及其定义所实现的，也就是说如果我们要测试新的内容，需要重新进行清理构建。

3.2不同名称的值映射

前两步的测试性学习我们理解到MapStruct可以在不修改接口代码的情况下快速实现源实体向目标实体的映射，那如果源与目标实体存在不同名字段呢？我们尝试将目标类字段换个名字：

public class TestTarget {
    private int anotherInteger;
    private String anotherStr;
//setter and getter
}

当然别忘了重新构建你的测试项目（每次重复的构建或许很麻烦，但相信我，比起集成到后去费劲心力排查各种bug，学习性测试过程中的一些小的复出其实更加高效）。这次的执行结果显示源与目标没有实现映射：

java.lang.AssertionError: 
Expected :1
Actual   :0

换上我们的红帽子去找寻原因，在MapStruct中给出一种由源向目标的自定义字段映射方案，按照指导我们尝试修改Mapper接口实现类：

@Mapper
public interface TestMapper {
    TestMapper INSTANCE = Mappers.getMapper(TestMapper.class);

    @Mapping(source = "integer", target = "anotherInteger")
    @Mapping(source = "str", target = "anotherStr")
    TestTarget source2target(TestSource source);
}

重新构建后执行测试，我们得到了令人愉悦的绿色通过结果。

3.3更多的内容

后续我还进行了在项目中需要用到的诸如集合映射、类型转换映射、自定义方法映射等功能，以及我自己感兴趣的对于表达式语法的支持，受限于文章的篇幅我不打算完整的将代码都罗列在这里，当然介绍MapStruct的各种功能也不是我这篇文章的主旨。

我要说的是，在一系列测试之后，我们不仅对工具及其用法有了更深入的认知，也极有可能对文档中未提及的特殊情况以及边界条件有了自身的见解，更甚至帮助工具开发者发现了他的的某些代码bug。除此之外，这些认知和条件的梳理以代码的形式长久的保留在了我们的项目中，后续工具升级的过程中，我们不需要逐个去比对自己所用到的功能在工具新旧版本中的区别并去评估对自己系统的影响，我们只需要单纯的执行一下最初的学习性测试内容，任何可能造成系统异常的工具升级导致的问题都会快速地暴露在我们面前。

4.后续

相比于写一行代码并祈祷其能够正确的工作，我更推崇用测试的方式去验证自己的观点与逻辑。文章中提到的红绿帽子切换的极限编程工作流思维以及由测试去驱动开发的编程思想都曾在我自身的软件开发实践中得以应用并有所收获，测试代码除了可以当做项目的“安全网”，也可能是我们学习一项新工具过程中的指南针，而这，就是学习性测试（Learning Tests）。

参考：

[1] James Newkirk, Test-Driven Development in Microsoft .NET, also referenced in Beck’s TDD and Clean Code by Robert C. Martin.

[2] MapStruct – Java bean mappings, the easy way!

[3] https://medium.com/microsoftazure/learning-tests-and-how-they-help-cover-every-line-of-code-da41c74043b

[4] Learning Tests or How I Learned the Linkedin Api Effortlessly | FrederikBanke.com