• 前端做自动化测试 —— 用TDD的思想做组件测试

    Test-Driven Development(测试驱动开发,以下简述TDD)是一种设计方法论, 原理是在开发功能代码之前, 先编写单元测试用例代码, 通过测试来推动整个开发的进行.

    本文详细描述了在创作 react-stillness-component,

     组件的过程中, 是如何学习 TDD 的思想来完成功能开发以及测试的

    一.前言-自动化测试相关

    本篇文章是针对编写react组件过程中所产生的质量与功能保障的角度去写的,由于涉及到部分的名词,可能需要提前有部分的自动化测试相关知识;

    本文的侧重点主要是在如何设计以及为何要使用 tdd 的方式来做组件测试,有任何的问题,也欢迎与作者进行讨论 😁

    二.我所认为的 tdd 实际落地流程

    首先简单回顾一下 tdd:

    对应的实际行为可能是(来源于 wiki)

    1. 添加一个测试用例
    2. 运行该测试用例,得到失败的结果(因为还没有实现任何功能)
    3. 编写刚好能通过的最简单的代码
    4. 重新运行该测试用例,得到成功的结果
    5. 根据需要进行重构,并保证每次重构之后都能通过之前的测试用例
    6. 重复这个步骤,直至完成整个开发

    当然,在实际的开发过程中,作者也针对现实情况做了一定的改造,先看下改造之后的流程:

    这里主要是针对前端组件场景增加了一些比较重要的步骤

    • 确认用户场景,在什么样的情况下才考虑用到这个组件?包括了普通用户和专业用户涉及到的场景.需要考虑到涉及到 UI 框架的场景
    • 确认用户行为,也就是用户的具体操作是什么?可以先从自身的角度出发,再进行实际调研,观察类似的组件是如何被使用的
    • 确认用户环境,这里的环境包括了现代浏览器环境以及框架自身所处的开发环境.

    在每次完成测试用例编写之前先是确认环节,保证功能不偏离初心;在每次测试完之后,再进行验证,而验证的手段可以是 BDD(后文会提到)也可以结合现实线上例子进行结合考虑,如果可以解决实际问题,则证明功能已完成.

    当然,由于作者本身的日常习惯是先列计划 😂,这次也不例外:

    可以看到最下面的部分就是与 TDD 相关的测试用例规划,实际编写用例过程中会有额外的情况,因此第二个部分也就是 e2e 模拟测试就是框定的使用范围,第一期只要不超出即可.

    下面来看实际案例

    三.实际案例

    本文中使用的测试框架为**jest**,相关配置可参考问题汇总的第一点

    provider

    首先从最外层开始,该组件内部大量使用了context,因此,需要提供一个全局的provider,因为provider的value来源于createStillnessManager(),所以我们的第一个例子就是判断当提供了这个方法的时候,provider是否可以正常运行

    1. it('Verify that the StillnessManager is correct', () => {
    2.   let capturedManager;
    3.   let manager = createStillnessManager(); // let mockManager: any = jest.fn();
    4.  
    5.   render(
    6.     <StillnessContext.Provider value={{ stillnessManager: manager }}>
    7.       <StillnessContext.Consumer>
    8.         {({ stillnessManager }) => {
    9.           capturedManager = stillnessManager;
    10.           return null;
    11.         }}
    12.       </StillnessContext.Consumer>
    13.     </StillnessContext.Provider>
    14.   );
    15.  
    16.   expect(capturedManager).toBe(manager);
    17. });
    18. 复制代码

    这里前期使用的其实是jest mock functions,当createStillnessManager()编写完成之后,才被替换成真实的函数,两者的区别在于mock的方式可以过滤掉provider编写代码时的干扰项

    那我们现在就可以开始 run test 了,当然,这时由于代码已编写完毕,无论是使用真实的参数还是模拟的参数都可以得到成功的例子.

    而在一开始,未编写代码时,就可以遵循流程,编写真实代码了.

    provider除了初始化之外,当然还会有其他功能,比如:

    • 卸载时会自动清除全局的缓存对象
    • 预防多个 provider 嵌套产生的错误,需要主动提醒用户

    而针对这两点,我们就可以继续写测试用例了

    1. it('stores StillnessManager in global context and cleans up on unmount', () => {
    2.   let capturedManager;
    3.  
    4.   const { container, unmount } = render(
    5.     <StillnessProvider>
    6.       <StillnessContext.Consumer>
    7.         {({ stillnessManager }) => {
    8.           capturedManager = stillnessManager;
    9.           return null;
    10.         }}
    11.       </StillnessContext.Consumer>
    12.     </StillnessProvider>
    13.   );
    14.  
    15.   const globalInstance = () => (global as any)[INSTANCE_SYM] as any;
    16.  
    17.   expect(globalInstance().stillnessManager).toEqual(capturedManager);
    18.   unmount();
    19.   expect(globalInstance()).toEqual(null);
    20. });
    21. 复制代码

    可以看到,这里通过调用返回的方法,从而达到了模拟卸载的效果.

    class Component

    首先来看下整个库的核心, ,相比较经过HOC包装之后的组件,原始组件的 props 就要复杂的多了

    • uniqueId: UniqueId;
    • parentId: UniqueId;
    • parentIsStillness: boolean;
    • isStillness: boolean;
    • stillnessManager: StillnessManager;

    测试用例也围绕这几点即可,举个例子:

    1. it('Does it prompt an error message when there is no context?', () => {
    2.   global.console.error = jest.fn();
    3.  
    4.   expect(() => {
    5.     render(
    6.       <OffscreenComponent
    7.         visible={true}
    8.         isStillness={false}
    9.         uniqueId="test1"
    10.         parentId={rootId}
    11.         parentIsStillness={false}
    12.       >
    13.         <div />
    14.       </OffscreenComponent>
    15.     );
    16.   }).toThrow(/stillnessManager is required/i);
    17. });
    18. 复制代码

    组件是没办法在缺少 context 的情况下运行的,那我们在编写例子的时候只要排除这个参数就行,如果组件捕获了异常并抛出了,则说明功能是 ok 的,这个属于较为简单的例子

    来看一个更加复杂的:

    1. it('When the passed isStillness changes, clear the corresponding dom element or reload the original one', async () => {
    2.   const Demo = ({ isStillness }: any) => {
    3.     return (
    4.       <OffscreenComponent
    5.         visible={true}
    6.         isStillness={isStillness}
    7.         uniqueId="test1"
    8.         stillnessManager={mockStillnessManager()}
    9.         parentId={rootId}
    10.         parentIsStillness={false}
    11.       >
    12.         <div data-testid="content" />
    13.       </OffscreenComponent>
    14.     );
    15.   };
    16.  
    17.   const { queryByTestId, rerender } = render(<Demo isStillness={false} />);
    18.  
    19.   rerender(<Demo isStillness={true} />);
    20.   expect(queryByTestId('content')).not.toBeInTheDocument();
    21.  
    22.   rerender(<Demo isStillness={false} />);
    23.   expect(queryByTestId('content')).toBeInTheDocument();
    24. });
    25. 复制代码

    组件的isStillness属性是比较重要的,也是用来控制组件的静止与否的条件,在这里通过真实模拟render,并通过修改传参的方法,来直接模拟效果,如果传递了true,则组件应该会渲染在 body 中,也就是查找id为content的元素一定可以找到,反之就找不到.

    通过这种方法,就可以测试 class Component

    更多例子请参考 Offscreen.spec.tsx

    HOC

    HOC是如何进行测试的呢,以组件为例:

    其 props 为:

    • visible:boolean 类型,控制组件是否静止
    • type:string or number,标识组件的类型,可重复,同一类型的静止行为会保持一致
    • scrollRest:boolean 类型,控制组件静止时是否缓存滚动位置

    但这些props实际上是经过处理传递给组件的,

    对于HOC自身来说,只需要保证在未找到context时进行捕获异常即可:

    1. it('throw an error if rendered', () => {
    2.   console.error = jest.fn();
    3.  
    4.   class TestClass extends React.Component<
    5.     React.PropsWithChildren<OffscreenInnerProps>
    6.   > {}
    7.  
    8.   const DecoratedClass = withNodeBridge(TestClass);
    9.  
    10.   expect(() => {
    11.     render(<DecoratedClass visible />);
    12.   }).toThrow(/Expected stillness component context/);
    13. });
    14. 复制代码

    至于上面的props,由于涉及到了其他模块,属于BDD测试的范畴了,会在下一篇 BDD 测试相关进行介绍

    hooks

    针对hooks相关,需要用到 @testing-library/react-hooks 该库可以直接运行 hooks 并断言结果

    举例说明:

    现在有一个根据依赖项从而返回最新结果的 hooks useOptionalFactory

    代码为:

    1. function useOptionalFactory<T>(
    2.   arg: FactoryOrInstance<T>,
    3.   deps?: unknown[]
    4. ): T {
    5.   const memoDeps = [...(deps || [])];
    6.   if (deps == null && typeof arg !== 'function') {
    7.     memoDeps.push(arg);
    8.   }
    9.   return useMemo<T>(() => {
    10.     return typeof arg === 'function' ? (arg as () => T)() : (arg as T);
    11.   }, memoDeps);
    12. }
    13. 复制代码

    测试用例的代码为:

    1. import { renderHook, act } from '@testing-library/react-hooks';
    2.  
    3. const useTest = () => {
    4.   const [count, setCount] = React.useState(0);
    5.  
    6.   const addCount = () => {
    7.     setCount(count + 1);
    8.   };
    9.  
    10.   const optionFactoryFn = useOptionalFactory(
    11.     () => ({
    12.       collect: () => {
    13.         return {};
    14.       },
    15.     }),
    16.     [count]
    17.   );
    18.  
    19.   return { addCount, optionFactoryFn };
    20. };
    21.  
    22. describe('useOptionalFactory', () => {
    23.   let hook;
    24.   it('Depending on the variation of the dependency value, different results are generated', () => {
    25.     act(() => {
    26.       hook = renderHook(() => useTest());
    27.     });
    28.  
    29.     let memoValue = hook.result.current.optionFactoryFn;
    30.  
    31.     act(() => {
    32.       hook.result.current.addCount();
    33.     });
    34.  
    35.     expect(memoValue).not.toStrictEqual(hook.result.current.optionFactoryFn);
    36.   });
    37. });
    38. 复制代码

    通过使用 renderHooks() 与 act(),即可简单进行测试,当测试的依赖项变化时,返回值则跟随进行变化.

    四.问题汇总

    1. 如何搭建测试环境?

      整体架构为lerna+Typescript+React+rollup+Jest,其实社区也有了很多的实例了,这里只介绍搭建过程中遇到的问题,

      • 如何单独搭建子包的测试环境? lerna 的架构,很好的分离了每个包的环境,可以使用不同的测试框架在每个子包中,单独配置,举例:

        可以在每个包中配置不同的 jest.config

      • 测试代码也希望使用Typescript?

        1. // jest-transformer.js
        2. const babelJest = require('babel-jest');
        3.  
        4. module.exports = babelJest.createTransformer({
        5.   presets: [
        6.     [
        7.       '@babel/preset-env',
        8.       {
        9.         targets: {
        10.           node: 'current',
        11.           esmodules: true,
        12.         },
        13.         bugfixes: true,
        14.         loose: true,
        15.       },
        16.     ],
        17.     '@babel/preset-typescript',
        18.   ],
        19.   plugins: [
        20.     ['@babel/plugin-proposal-class-properties', { loose: true }],
        21.     '@babel/plugin-transform-react-jsx',
        22.     ['@babel/plugin-proposal-private-methods', { loose: true }],
        23.     [
        24.       '@babel/plugin-proposal-private-property-in-object',
        25.       { loose: true },
        26.     ],
        27.     '@babel/plugin-proposal-object-rest-spread',
        28.     '@babel/plugin-transform-runtime',
        29.   ],
        30. });
        31.  
        32. //jest.config.js
        33. module.exports = {
        34.   setupFilesAfterEnv: ['./jest-setup.ts'],
        35.   testMatch: ["**/__tests__/**/?(*.)(spec|test).[jt]s?(x)"],
        36.   // testRegex: 'decorateHandler.spec.tsx',
        37.   transform: {
        38.     "\\.[jt]sx?$": "./jest-transformer.js",
        39.   },
        40.   collectCoverageFrom: [
        41.     '**/src/**/*.tsx',
        42.     '**/src/**/*.ts',
        43.     '!**/__tests__/**',
        44.     '!**/dist/**',
        45.   ],
        46.   globals: {
        47.     __DEV__: true,
        48.   },
        49. };
        50. 复制代码

        只需要增加transform配置即可

    2. 如何测试实际的渲染效果?

      可使用 @testing-library/jest-dom,该库提供了关于 DOM 状态的相关 jest 匹配器,可用来检查元素的树形,文本,样式等,本文也介绍了一些,比如:

      • toBeInTheDocument:判断文档中是否存在元素
      • toHaveClass:判断给定元素中是否在其class属性中具有相应的类名
      • toBeVisible:判断给定元素是否对用户可见

    3. 想要单独测试某一个例子怎么办?

      1. //jest.config.js
      2. module.exports = {
      3.   setupFilesAfterEnv: ['./jest-setup.ts'],
      4.   //testMatch: ["**/__tests__/**/?(*.)(spec|test).[jt]s?(x)"],
      5.   testRegex: 'decorateHandler.spec.tsx',
      6.   transform: {
      7.     "\\.[jt]sx?$": "./jest-transformer.js",
      8.   },
      9.   collectCoverageFrom: [
      10.     '**/src/**/*.tsx',
      11.     '**/src/**/*.ts',
      12.     '!**/__tests__/**',
      13.     '!**/dist/**',
      14.   ],
      15.   globals: {
      16.     __DEV__: true,
      17.   },
      18. };
      19. 复制代码

    4. 如何自动测试?

      组件库中的自动流程体现在推送分支和github的自动发版流程上

      1. // package.json
      2. "scripts": {
      3.   "test": "jest --projects ./packages/*/",
      4.   "test:coverage": "jest --coverage --projects ./packages/*/",
      5.   "precommit": "lint-staged",
      6.   "release": "bash ./scripts/release.sh",
      7.   "lint:staged": "lint-staged",
      8.   "ci": "run-s test:coverage vs git-is-clean",
      9. },
      10. "lint-staged": {
      11.   "*./packages/**/*.{js,ts,json,css,less,md}": [
      12.     "prettier --write",
      13.     "yarn lint"
      14.   ],
      15.   "*./packages/**/__tests__/**/?(*.)(spec|test).[jt]s?(x)": [
      16.     "yarn test"
      17.   ]
      18. }
      19. 复制代码

      可以简单的修改配置文件,使用testRegex针对某一个文件进行测试,当然,这里作者只是列出了自身认为比较简单的方法,如果有更简单的方法,欢迎提出👏👏

    五.总结

    本文总结了在编写一个 react 组件的过程中是如何思考以及组织测试代码的,当然,在实际的生产开发阶段,有一定的测试时间才是最宝贵的,也是 TDD 测试能推行的基础,如果说 TDD 测试保证了基础功能,那么 BDD 测试则扩展了使用场景;

    按照代码比例来说,作者自身认为 TDD 占 70%,而 BDD 则占到剩下的 30%;

    这里面是性价比的考量,毕竟日常工作中,需求的改动是很频繁的,这也就意味着组件可能会遇到各种不同的场景,而 TDD 测试用例大部分仍然可以保留,但 BDD 测试就不一定了.

    这是 《前端如何做组件测试》的第一篇,如果有任何问题,欢迎讨论.

    学习资源分享和交流讨论

    最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走

    ​这些资料，对于在从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…….

  • 相关阅读:
    MongoDB 中的 push 操作(将文档插入到数组中)
    npm install卡在sill idealTree buildDeps没有反应，安装失灵
    前后端传参
    数字孪生|数字孪生装备-关键技术和发展阶段
    一文道清什么是SPL
    【剑指offer|图解|双指针】训练计划 I + 删除有序数组中的重复项
    vue3 快速入门系列 —— vue3 路由
    深度学习(part3)--深度学习框架tensorflow
    ZooKeeper启停脚本
    k8s-----25、资源调度-ResourceQuota资源配额、资源限制limitrange、服务质量QoS
  • 原文地址：https://blog.csdn.net/IT_LanTian/article/details/127089807