关于前端:单测在商家前端业务中的实践

商家零碎是提供给得物商家在得物平台上能够稳固经营的服务抓手，前端代码也随同着零碎的倒退而一直壮大。这样将 导致文档却更新不及时，最初想再通过这些文档回溯业务逻辑也十分艰难。

且若代码构造上没有关注，动辄就会产出一个大几千行的文件😲，人员交替保护的时候很难理清外面的逻辑，保护十分艰难。

为解决上述痛点，早在单测之前，团队上曾经做了一些其余事件来使文档更清晰、代码品质更高，如写需要系分文档、通过 整洁架构 (The clean architecture) 对代码进行分层、code review 等等。但这些其实都只是外在的束缚，只有外在的代码能真正经得住单测的斟酌，能力更好的保障咱们的代码品质。

但目前现状是前端大部分状况下都没有接触到单测，仅在组件库或工具类的我的项目里有一些。这并不代表业务我的项目中前端就无奈单测，而是因为一些客观原因，导致前端在单测上的投入绝对较少。

前端开发的内容比拟杂，一个需要不仅仅是性能函数的编写，还有 UI 的展现、dom 交互的绑定等等，且若想单测齐全笼罩，将蕴含十分多的内容，对业务前端来说老本太高。
前端 UI 框架层出不穷，在业务开发的时候，依赖框架也很容易将代码逻辑和 UI 等齐全耦合在一起，导致一个文件上千行，很难对这种代码找到单测的切入点。
单测上手自身就有肯定的门槛，要写出可维护性高的单测更不简略，会让不相熟的人望而生畏。

鉴于下面的第一个难点，前端波及的内容太杂，咱们必定无奈给所有的代码笼罩单测，去测到代码的各个角落。再联合上咱们本人自身的痛点（文档更新不及时，人员轮转老本高），因而以“单测即文档”为指标，咱们只用笼罩业务逻辑上的单测即可，只关注业务流程的连接，通过用例将业务流程讲清楚，对于单测的分支覆盖率也不做强硬的要求。

Use Cases

因而，要在团队落地单测的第一步即是 辨认出实现业务逻辑的代码模块。若在较早的时候，想找到这个切入点可能还真没有什么好的办法，因为全是几千行的大文件，且逻辑和 UI 都耦合在一起。

正如后面所说，在单测推广前，咱们曾经做了一些代码筹备工作。得益于 “整洁架构” 的推广，在开发需要的同时，已逐步在对代码进行解耦重构，其外围就是根据各局部代码作用的不同将其拆分成不同的档次，在各层次间制订了明确的 依赖准则 ， 达到与框架无关、与内部服务无关、并可测试的目标。

通过分层后，咱们将业务逻辑次要都落在了 usecase 这一层，在咱们的代码构造上，它的作用是将业务流程串联起来，且它仅依赖 entities(次要对服务端返回数据做适配和查看) 层，逻辑独立不会因为依赖框架或 UI 的变动而无奈运行。

相较于后端服务，前端利用通常并不会承载如计算、存储等实实在在的业务逻辑，同时因为当初微服务架构的风行，前端利用往往会承当很重的胶水逻辑，行将各个微服务的逻辑串联在一起，从而跑通业务流程。

因而，前端在编写 usecase 的时候，咱们会更重视奴才函数的拆分，让主 usecase 更纯正的去形容业务流程，而将局部具体的实现拆分到子函数中去实现。

/*
    usecase 聚焦流程的形容，诸如 url 链接拼接、活动期查问等具体逻辑都拆分到了其余的模块中
*/
async function exportActivityLog({count, formValues}: {count: number;formValues: LogData}) {if (count > 5000) {message.error('导出文件数量不得超过 5000!')
    return
  }
  const res = await checkIsDuringTheEventApi()
  if (res.isDuring) {message.error('流动期间，性能暂不可用，如有疑难分割经营');
    return
  }
  const url = generateDownloadUrl({formValues})
  downloadExcelFile(url)
}

function generateDownloadUrl() {// 省略}

因而，对 usecase 层写单测，正是咱们要找的最好切入点，其既能满足咱们将业务文档进行补充，同时又能有单测模块的产出，保障咱们的代码品质和程序的稳定性。

在辨认出要笼罩单测的代码模块之后，下一步天然就是落地单测用例。

后面已说过，写单测自身就有肯定的门槛，但既然要写就应写可维护性和稳定性高的单测。否则代码略微一重构，单测崩了😱；或代码真崩了的时候，单测却没又通过了😅。

依据后面的形容能够看出，咱们对于用例的可读性 (文档性) 和稳定性有极高的诉求，对于用例所测试的逻辑范畴要求不高，这个准则对于后续的单测用例的设计取舍会有很大的影响。

首先咱们须要确定设计用例的切入点，目前单测社区内比拟风行的模式无非 TDD 和 BDD 两种：

TDD：测试驱动开发，偏差于去测到函数的各个性能运行的后果是否合乎预期，因为是通过先写用例去驱动业务逻辑的实现，因而用例的设计往往更偏技术实现。

BDD：行为驱动开发 ，流程上是 TDD 模式的一种分支，区别在于在构思用例的时候更多的是以用户行为(user story) 的角度去思考。

对于两者更多的区别，大家能够网上查阅到更多的材料，这里就不再赘述。为了咱们单测的稳固可维护性，且以文档为导向的咱们，天然是选用了 BDD 的模式，只测业务行为逻辑，不关注性能函数的输入正确与否（这块目前可在自测和测试兄弟团队那边帮忙保障）。这样除非业务流程产生变更，否则代码个别的重构或调整都不会影响到单测的运行，不会造成单测的雪崩。

在用例构造上，为了配合“单测即文档”的初衷并更好的配合 BDD，咱们在社区常见的 AAA(Arrange-Act-Assert)和 GWT(Given-When-Then)两种构造之间抉择了后者。

无论 AAA 还是 GWT 最终都会造成一个三段式的用例构造，其区别依然在于 AAA 的构思更偏向于技术实现，GWT 更偏向于业务流程。尽管构造一样，但设计进去的用例内容会有很大区别。

Given-When-Then

Given：一个上下文，指定和筹备测试的预设
When： 进行一系列操作，即所要执行的操作
Then： 失去可察看的后果，即须要检测的断言

咱们依据 GWT 的提供了单测的根本模板，供组内同学写单测时间接应用。

function init() {const checkIsDuringTheEventApi = jest.fn();
  const downloadExcelFile = jest.fn();
  const exportActivityLog = buildMakeExportActivityLog({checkIsDuringTheEventApi, downloadExcelFile})

  return {
    checkIsDuringTheEventApi,
    downloadExcelFile,
    exportActivityLog
  }
}

describe('spec', () => {it('test', () => {
    // Given  筹备用例所需的上下文
    const {checkIsDuringTheEventApi, downloadExcelFile, exportActivityLog} = init();

    // When 调用待测的函数
    exportActivityLog()

    // Then  断言
    expect('expect')
  })

对于一些校验简略模型的用例，通过 init 函数做一层封装就够用了。但对于业务逻辑比较复杂，字段比拟多的模型，间接利用原生数据进行初始化对用例的可读性并不敌对。

describe('spec', () => {it('集体卖家未发货的订单，容许进行勾销操作', () => {
    // Bad case: 依赖字段较多，这样手动去发明字段数据可读性并不敌对
    // 若 case 较多，这些字段要手动构建屡次
    action({
      status: Status. 待发货,
      merchantType: MerchantType. 集体卖家，// ... 还有一些其余必传字段
    })
  })
}

对于这种简单场景，咱们偏向于应用 builder 模式来结构数据，在较小的开发成本下保障用例的可读性和可维护性。



describe('spec', () => {it('集体卖家未发货的订单，容许进行勾销操作', () => {
        // Good case：通过 builder 实现逻辑的复用和信息的聚焦
        const order = new OrderBuilder()
          .status("待发货")
          .merchantType("集体卖家")
          .build()

        action(order)

    })
})

既然是要作为文档应用，那用例形容上也显得至关重要了。相比 TDD 对性能函数的单测，咱们形容齐全于 GWT 的用例构造对应 (When 时常会被省略掉)，咱们并不关怀具体的技术实现细节，更多的是形容的这个业务的行为流程，思考函数最终想做什么，达到什么目标。基于用意，把被测函数当做黑盒，不必关注其中间的实现细节，到底生成了什么长期变量、循环了几次、有什么判断等，而是通过用例形容将业务流程讲清楚。

describe('导出流动日志', () => {it('导出时，先查问以后活动状态，若状态是未在进行中，则执行导出操作', () => {// 省略...})
  it('导出时，若导出数量大于 5000 条，将不容许导出', () => {// 省略...})
})

下面🌰是导出流动日志的一个操作，能够看出，用例的形容不会像测性能函数那样精简（入参是 a，调用了啥函数必须返回 b 之类），然而将导出流动时，相应的调用流程和条件形容了进去，这样其他人在接手这块业务时，通过这个用例就能分明晓得在导出流动日志时需要上有些什么限度以及要做的操作。

在确定好用例的设计思路和构造之后，咱们在用例的校验内容上也做了一些取舍。针对社区上主导的经典测试 (Classical) 和模仿测试 (Mockist) 两大阵营，联合“单测即文档“的理念，咱们对于业务流程的验证诉求十分强烈，因而抉择了后者。

Classical格调是尽可能的应用实在对象和函数，让函数以及依赖都实在的执行；绝对的，Mockist是想尽办法去 mock，主张将所调用的被测函数全副 mock。存在即正当，两个派各有利弊，并不存在肯定谁好谁差。

要对用到的函数进行 mock，在保障用例可维护性的前提下 (比方不 mock 文件门路)，咱们须要对函数的依赖关系进行整顿。得益于团队整洁架构的落地，目前利用的 usecase 层都曾经通过 依赖倒置 对依赖关系做了很好的治理(usecase 只依赖 entity)。

export default function buildMakeExportActivityLog({checkIsDuringTheEventApi,downloadExcelFile}) {async function exportActivityLog({count,formValues}) {if (count > 5000) {message.error('导出文件数量不得超过 5000!')
      return
    }
    const res = await checkIsDuringTheEventApi()
    if (res.isDuring) {message.error('流动期间，性能暂不可用，如有疑难分割经营');
      return
    }
    const url = generateDownloadUrl({formValues})
    downloadExcelFile(url)
  }
}

// index.ts
import {checkIsDuringTheEventApi} from '@/services/activity'
import {downloadExcelFile} from '@/utils'
import buildMakeExportActivityLog from './makeExportActivityLog'

export const exportActivityLog = buildMakeExportActivityLog({cancel,printSaleTicket})

能够看到 checkIsDuringTheEventApi 以及 downloadExcelFile 这两个函数最终作为参数传入到理论的函数中，他们一个将会去发动申请，一个是会调用 window 的办法进行下载，通过依赖倒置就能不便咱们对其进行模仿，在单测时就不会去实在执行这两个函数。

function init() {const checkIsDuringTheEventApi = jest.fn();
  const downloadExcelFile = jest.fn();
  const exportActivityLog = buildMakeExportActivityLog({checkIsDuringTheEventApi, downloadExcelFile})
  return {
    checkIsDuringTheEventApi,
    downloadExcelFile,
    exportActivityLog
  }
}

usecase中时常会有依赖的函数要去发动申请，在单测时咱们不会去实在去发动这个申请，因而对于这类函数，咱们都应 mock 掉，这样可保障咱们用例的速度和稳定性。当然理论在写单测中，咱们也不应该成为一个齐全的 mockist，无休止的进行 mock，更好的形式是 两者联合，否则滥用 mock 反而会导致单测写起来会更繁琐（因为要去 mock 所有调用的函数实现或场景），而且实在代码写起来也会很顺当（所有内部函数都依赖倒置）。

一个用例正确与否，最终依赖的是最初的断言，那对咱们来说该怎么进行断言呢，如后面始终强调的一样，咱们测的是逻辑行为，因而需断言的是某个行为的是否执行或者是否达到了什么目标。联合后面的 mock，咱们可对函数的调用状况进行捕捉，针对下面发动勾销退款的函数，断言的例子如下：

describe('导出流动日志', () => {it('导出时，先查问以后活动状态，若状态是未在进行中，则执行导出操作', () => {
    // 省略...
    expect(downloadExcelFile).toBeCalled()})

  it('导出时，若导出数量大于 5000 条，将不容许导出', () => {
    // 省略...
    expect(downloadExcelFile).not.toBeCalled();})
})

如上，断言的内容不是函数的实现细节，如参数是否正确，而是只断言行为是否执行，它能尽量保障做到若代码重构后，单测用例在不批改的状况下仍然能强壮的运行，其只依赖需要的变更而做更改。同时为了保护用例的稳定性，单个用例咱们通常仅执行一次断言 (繁多职责)， 断言的内容严格和形容的“Then”局部对应。

商家以 “单测即文档” 的理念为落地方向，在代码设计以及用例的构思、构造、断言、形容等环节都做了肯定取舍，最终在用例的书写老本、稳定性、可读性等各个方面获得了绝对较好的均衡。

目前组内各个我的项目已逐步积淀了几百个用例，团队内互相声援或本人回顾时，通过这些用例就能晓得这块逻辑在做什么事，在批改这些需要时通过测试用例也能尽快晓得根本的业务逻辑，有了单测的保障，改起代码来更有底气，代码构造上，也更加的正当。在大家逐步相熟单测后，后续更会缓缓做到性能函数、UI 等的单测笼罩，大家一起来保障商家前端业务的稳固倒退。

参考文章：
“整洁架构”和商家前端的重构之路：
https://mp.weixin.qq.com/s/Sg…

The Difference Between TDD and BDD：
https://joshldavis.com/2013/0…
https://lassala.net/2017/07/2…

jest 文档：
https://jestjs.io/zh-Hans/doc…

* 文 / 淳猛
关注得物技术，每周一三五晚 18:30 更新技术干货
要是感觉文章对你有帮忙的话，欢送评论转发点赞～

关于前端:单测在商家前端业务中的实践

1. 背景

2. 前端单测的难点

3. 单测即文档

4. 单测实际

4.1 用例设计

4.2 用例构造

4.3 用例形容

4.4 用例断言

5. 结语