利用Clean Architecture写好白盒测试

时间 2020-09-19

标签利用 clean architecture 写好测试繁體版

原文原文链接

本文首发于泊浮目的简书: https://www.jianshu.com/u/204...

版本	日期	备注
1.0	2020.9.13	文章首发

前言

Clean Architecture是Bob大叔在2012年提出的一个架构模型。其根据过去几十年中的一系列架构提炼而成：java

Hexagonal Architecture：由 Alistair Cockburn 首先提出
DCI：由 James Coplien 和Trygve Reenskaug 首先提出
BCE：由 Ivar Jacobson 在他的 Obect Oriented Software Engineering: A Use-Case Driven Approach 一书中首先提出

根据这些架构设计出来的系统，每每具备如下特色：算法

独立于框架：这些系统的架构并不依赖某个功能丰富的框架之中的某个函数。框架能够被当成工具来使用，但不须要让系统来适应框架。
可被测试：这些系统的业务逻辑可以脱离 UI、数据库、Web 服务以及其余的外部元素来进行测试。
独立于 UI ：这些系统的 UI 变动起来很容易，不须要修改其余的系统部分。例如，咱们能够在不修改业务逻辑的前提下将一个系统的 UI 由 Web 界面替换成命令行界面。
独立于数据库：咱们能够轻易将这些系统使用的 Oracle 、SQL Server 替换成 Mongo、BigTable、 CouchDB 之类的数据库。由于业务逻辑与数据库之间已经完成告终耦。独立于任何外部机构：这些系统的业务逻辑并不须要知道任何其余外部接口的存在。

关于Clean Architecture的介绍到此为止，有兴趣的同窗能够自行查阅google。spring

背景

最近写了不少业务代码，由于每一个组件都是分布式部署的，致使手动测试时很是的痛苦，耗时耗力。因而我便开始思考针对业务的自动化测试方案。数据库

目前业务中一部分的代码使用了Storm这个框架，咱们挑一个方便理解的用例，这里大概涉及三个组件：编程

ReadSpout：从kafka、database读取消息，并将其下发
DispatcherBolt：读取上游下发的消息，并根据必定的规则分发——好比主键（最近又增长了自定义键和组合键），而后将关键字相同的数据放在一块儿，而后下发
KafkaWriteBolt：读取上游下发的消息，将关键字同样的数据写入kafka

DispatcherBolt的核心代码大体以下：segmentfault

@Override
    public void prepare(Map conf, TopologyContext context, OutputCollector collector) {
        super.prepare(conf, context, collector);
        try {
            init();
        } catch (Exception e) {
            collector.reportError(e);
            throw new RuntimeException(e);
        }
    }

    @Override
    public void execute(Tuple dataTuple) {
        this.input = dataTuple;
        try {
            Object obj = dataTuple.getValueByField(EmitFields.MESSAGE);
            String key = (String) dataTuple.getValueByField(EmitFields.GROUP_FIELD);
            List<MessageEntry> messageEntries = (List<MessageEntry>) obj;
            emitMessageEntry(key, messageEntries);
            this.collector.ack(dataTuple);
        } catch (Exception e) {
            logger.info("Dispatcher Execute error: ", e);
            this.collector.reportError(e);
            this.collector.fail(dataTuple);
        }
    }

    private void emitMessageEntry(String key, List<MessageEntry> messageEntries) throws Exception {
        long lastPos = 0L, uniquePos = 0L, payloadSize = 0L;
        UmsMessageBuilder builder = null;
        // 处理任一schema 分组的表数据
        String tableName = messageEntries.get(0).getEntryHeader().getTableName();
        for (MessageEntry msgEntry : messageEntries) {
            EntryHeader header = msgEntry.getEntryHeader();
            header.setLastPosition(lastPos);
            // 若使用schema 进行分组，则同一组数据中可能会出现多张表的情形，须要处理表名出现切换的状况
            if (StringUtils.isEmpty(tableName) || (getExtractorConfig().getGroupType() == GroupType.SCHEMA && !StringUtils.equalsIgnoreCase(tableName, header.getTableName()))) {
                emitBuilderMessage(builder, key);
                builder = createUmsDataBuilder(msgEntry, destination, msgEntry.getBatchId(),
                        MediaType.DataSourceType.getTypeByName(getExtractorConfig().getNodeType()));
                payloadSize = 0;
            }
            // DDL处理
            if (msgEntry.isDdl()) {
                emitBuilderMessage(builder, key);
                executeDdlEvent(msgEntry);
                emitDDLMessage(key, msgEntry);
                builder = null;
                continue;
            }


            if (builder != null && msgEntry.getEntryHeader().getHeader().getSourceType().equalsIgnoreCase(MediaType.DataSourceType.ORACLE.getName())) {
                emitBoltMessage(key, builder.getMessage());
                builder = createUmsDataBuilder(msgEntry, destination, msgEntry.getBatchId(),
                        MediaType.DataSourceType.getTypeByName(getExtractorConfig().getNodeType()));
                payloadSize = 0;
            }
            // DML处理
            if (builder == null) {
                builder = createUmsDataBuilder(msgEntry, destination, msgEntry.getBatchId(),
                        MediaType.DataSourceType.getTypeByName(getExtractorConfig().getNodeType()));
                payloadSize = 0;
            }
            for (CanalEntry.RowData rowData : msgEntry.getRowDataLst()) {
                lastPos = Long.parseLong(header.getPosition()) + (++uniquePos);
                // 对UPDATE类型的增量数据特殊处理
                if (header.isUpdate()) {
                    if (getExtractorConfig().getOutputBeforeUpdateFlg()) {
                        payloadSize += appendUpdateBefore2Builder(builder, header, rowData, EventType.BEFORE.getValue().toLowerCase());
                    }
                    if (ExtractorHelper.isPkUpdate(rowData.getAfterColumnsList())) {
                        payloadSize += appendUpdateBefore2Builder(builder, header, rowData, getEventTypeForUMS(CanalEntry.EventType.DELETE));
                    }
                }

                List<Object> payloads = new ArrayList<>();
                payloadSize += appendRowData2Builder(payloads, builder, header, rowData);
                builder.appendPayload(payloads.toArray());
                }
            }

        }
        // 最后一批数据发送
        emitBuilderMessage(builder, key);
    }

注意，这里的两个方法prepare和execute都是框架暴露出来的接口，用于初始化时得到strom的上下文以及strom下发的对象。若是开发者使用不当，则会致使业务代码和框架耦合。设计模式

方案1：利用IOC

这个方案在早期的时候作过尝试，简单的来讲就是将中间那段emitMessageEntry相关的代码抽象成一个对象，并用接口表示。然而经过spring这种IOC框架注入进来，相似于：架构

override fun prepare(topoConf: MutableMap<String, Any>, context: TopologyContext, collector: OutputCollector) {
        super.prepare(topoConf, context, collector)
        try {
            init()
            this.dispatcherServer = IOCUtil.getBean(DispatcherServer::class.java).init(collector)
        } catch (e: Exception) {
            collector.reportError(e)
            throw RuntimeException(e)
        }
    }
    override fun execute(input: Tuple) {
            val obj = dataTuple.getValueByField(EmitFields.MESSAGE)
            val key = dataTuple.getValueByField(EmitFields.GROUP_FIELD) as String
            val messageEntries = obj as List<MessageEntry>
            dispatcherService.dispatcherLogical(messageEntries,key)
    }

这样咱们在单元测试里能够直接将dispatcherService类注入进来，并本身实现一个OutputCollector用于收集分发的数据。而后将mock的参数填入，并断言结果是否符合咱们的期待。app

但因为storm会涉及到分发相关事宜（如序列化），这会让业务代码有点变扭：框架

将这个dispatcherService成员在Bolt里声明为Transient
须要在初始化时初始化IOC容器
在初始化IOC容器后注入dispatcherService

能够看到，咱们为了测试，居然不得不修改业务代码来加入可有可无的逻辑，这显然不是一个好的方案。

方案2：Mockito

Mockito实现的方案对业务没有任何入侵性，直接写测试代码便可，写出来的代码相似于：

@RunWith(PowerMockRunner::class)
@PowerMockIgnore("javax.management.*")
class DispatcherBoltTest {

    private lateinit var config: AbstractSinkConfig
    private lateinit var outputCollector: OutputCollector
    private lateinit var tuple: Tuple


    @Before
    fun atBefore() {
        config = PowerMockito.mock(AbstractSinkConfig::class.java)
        outputCollector = PowerMockito.mock(OutputCollector::class.java)
        tuple = PowerMockito.mock(Tuple::class.java)
    }

    private fun init(dispatcherBoltImpl: DispatcherBoltImpl) {
        reset(config)
        reset(outputCollector)
        reset(tuple)
        dispatcherBoltImpl.prepare(mutableMapOf(), PowerMockito.mock(TopologyContext::class.java), outputCollector)
    }

    @Test
    fun testSingleUms() {
        //定义mock对象的一些行为
        `when`(config.configProps).thenReturn(Properties())

        //将须要测试的类实例化
        val dispatcherBoltImpl = DispatcherBoltImpl(config)
        init(dispatcherBoltImpl)

        val umsMap = generateSingleUmsBo()
        val boMap = getBoMap(intArrayOf(1))

        //定义mock对象的一些行为
        `when`(tuple.getValueByField(EmitFields.MESSAGE)).thenReturn(umsMap.messages)
        `when`(tuple.getValueByField(EmitFields.GROUP_FIELD)).thenReturn(umsMap.dispatchKey)
        `when`(tuple.getValueByField(EmitFields.EX_BO)).thenReturn(boMap)

        dispatcherBoltImpl.handleDataTuple(tuple)

        // 结果验证
        Mockito.verify(outputCollector, Mockito.times(1))
                .emit(EmitFields.DATA_MSG, tuple, Values(umsMap.dispatchKey, umsMap.messages,
                        boMap,
                        EmitFields.EMIT_TO_BOLT))
    }
}

逻辑很清晰易懂：先选择须要mock的对象，并定义其被mock的行为，而后把数据填装进去便可，最后根据结果校验——本质上将业务和框架的行为一块儿测试了进去。

但若是把视野放高点看，有两个潜在的问题须要考虑：

目前该类的业务逻辑比较简单，因此咱们须要关注的链路也较少——这体如今咱们对于mock对象的mock行为编写上。换句话说，该类越复杂，咱们就须要编写越多的mock代码。
目前咱们的业务和框架是紧耦合的，那么咱们测试时须要将框架的行为一同考虑进去。同时也意味着框架行为变更时（如升级），测试用例须要大量变动。亦或是更换框架时，测试用例会变得几乎不可用。**这已经违反整洁架构的原则了——业务须要独立于框架，而不是紧密耦合。

方案3：Clean Architecture

根据前面提到的，咱们要作的第一件事就是剥离业务和框架的耦合。那么该如何剥离呢？咱们直接拿出答案：

/**
 * 剥离与任何流处理框架的耦合，仅关注UMS分发的服务
 * */
interface DispatcherServer {

    fun dispatcherMessageEntry(key: String, messageEntries: List<MessageEntry>, destination: String,
                               tableToDispatchColumn: HashMap<String, Set<String>>,
                               resultConsumer: (group: MutableMap<Int, UmsMessageBuilder>, key: String) -> Unit,
                               executeDdlEventBlock: (messageEntry: MessageEntry) -> Unit,
                               ddlMessageConsumer: (key: String, messageEntry: MessageEntry) -> Unit)
}

咱们定义了三个函数型参数。利用这种方式，咱们能够轻易的将业务和框架隔离开来。因而代码调用起来就像这样：

override fun execute(dataTuple: Tuple) {
        input = dataTuple
        try {
            val obj = dataTuple.getValueByField(EmitFields.MESSAGE)
            val key = dataTuple.getValueByField(EmitFields.GROUP_FIELD) as String
            val messageEntries = obj as List<MessageEntry>
            dispatcherServer.dispatcherMessageEntry(key, messageEntries, destination, tableToDispatchColumn,
                    resultConsumer = { builder, innerKey -> emitBuilderMessage(builder, innerKey) },
                    executeDdlEventBlock = { entry -> executeDdlEvent(entry) },
                    ddlMessageConsumer = { innerKey, msgEntry -> emitDDLMessage(innerKey, msgEntry) }
            )

            collector.ack(dataTuple)
        } catch (e: Exception) {
            logger.info("Dispatcher Execute error: ", e)
            collector.reportError(e)
            collector.fail(dataTuple)
        }
    }

emitBuilderMessage、executeDdlEvent、emitDDLMessage只是DispatcherBolt中的一个私有方法，里面会将传入的数据经过collector按照必定规则下发下去。这样，咱们就将框架相关的代码放在了DispatcherBolt里。

而和框架无关的业务代码，咱们则能够将它放到DispatcherServer的实现中去。

测试的代码也能够专一在测试业务逻辑上：

@Test
    fun testUpdateRecords() {
        val originNamespace = "my_schema.my_table"
        val mockData = listOf(getUpdate1Data())
        val config = getMockConfig(extractorConfigJsonFile)
        config.outputBeforeUpdateFlg = false
        config.outputExtraValueFlg = false
        config.payloadType = PayloadType.SIZE
        config.maxPayloadSize = 10240
        val dispatcherServer = DispatcherServerImpl(config)
        val resultMap = mutableMapOf<Int, UmsMessageBuilder>()

        dispatcherServer.dispatcherMessageEntry(originNamespace, mockData, "M26", hashMapOf(),
                resultConsumer = { builder, innerKey ->
                    resultMap.putAll(builder)
                    Assert.assertEquals(innerKey, originNamespace)
                },
                executeDdlEventBlock = { throw  RuntimeException("这堆数据中不该该出现DDL事件") },
                ddlMessageConsumer = { _, _ -> throw  RuntimeException("这堆数据中不该该出现DDL相关的结果") })


        assertEquals(1, resultMap.keys.toSet().size, "当前数据中，应该被分为3组——根据主键分发原则，他们来自于不一样的主键")
        assertEquals(1, resultMap.size, "当前数据中，应该被分为3组——根据主键分发原则，他们来自于不一样的主键")
        val umsList = resultMap.values.map { it.message }
        umsList.forEach {
            Assert.assertEquals("m.M26.my_schema.my_table", it.schema.namespace)
            Assert.assertEquals(1, it.payloads.size)
            assertEquals(9, it.schema.fields.size, "5个扩展字段+4个schema字段应该为9")
            Assert.assertEquals("inc", it.protocol.type)
            Assert.assertEquals("2", it.protocol.version)
            assertEquals(MediaType.DataSourceType.MYSQL, KafkaKeyUtils.getDataSourceType(it))
        }
    }

看完了效果，咱们再来谈谈上面所用到技巧。其实这很像面向对象中的Strategy模式——定义一个算法接口，并将每一种算法都在这个接口下实现其逻辑，令同一个类型的算法可以互换使用。这样作的好处是算法的变化不影响使用方，也不受使用方的影响。而若是函数是一等公民的话，则会让创建和操纵各类策略的工做变得十分简单。

那么怎样是不简单的呢？若是用java的话，咱们得先定义一个专门的接口，声明一个方法，在使用时用匿名内部实现将它传入，但这其实没什么必要，由于咱们仅仅想传一个函数进去，而不是对象。典型的代码能够见：

ZStack源码剖析之设计模式鉴赏——策略模式： https://segmentfault.com/a/11...

设计模式要作的事不外乎减小代码冗余度，提升代码复用性。而在函数式语言中，复用主要表现为经过参数来传递做为第一等语言成分的函数，各类函数式编程库都频繁地运用了这种手法。与面向对象语言相比（以类型为单位），函数式语言的重用发生于较粗的粒度级别上（以行为为单位），着眼于提取一些共通的运做机制，并参数化地调整其行为。