使用 Webpack + Mocha 进行单元测试(二)

作为一名远程工作者,我并不能保证100%的电源供应,就目前的经验来看,我大约有30%的时间靠电池工作。所以我对能耗也比较敏感,把 eslint 和单元测试(mocha)放在 webpack 里做热加载,我觉得实在没什么必要,还是单独写单独跑吧。

查看 mocha-webpack 的 README,它对自己的介绍是:mocha-webpack 基本上等效于 $ webpack test.js output.js && mocha output.js 命令的封装,但是更高效、更强大。

让我们忽略后半句,先不去研究它高效和强大在什么地方,只看前半句。如果本质如此的话,那就不复杂,我只要写一个 webpack 配置文件生成所有的测试,然后跑这些测试就行了。最终方案:

  1. 一个入口文件,import 所有测试文件
  2. 用 webpack 打包入口文件,忽略掉不需要测试的内容(比如 CSS)
  3. 跑这个测试
  4. 平时写测试随便改下 import 路径就行了

测试文件多而杂,一个一个 import 太麻烦,可以写一个脚本帮我们:

const context = require.context('.', true, /.+\.test\.js?$/);
context.keys().forEach(context);
module.exports = context;

然后配合这样的配置文件即可:

const path = require('path');
const nodeExternals = require('webpack-node-externals');
const {resolve} = require('./webpack.base.config');

resolve.alias.test = path.resolve(__dirname, '../test');

const config = {
  target: 'node',
  entry: 'test/index.js',
  output: {
    path: path.resolve(__dirname, '../dist'),
    filename: 'test.build.js',
  },
  externals: [nodeExternals()],
  module: {
    rules: [
      {
        test: /\.vue$/,
        loader: 'vue-loader',
      },
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              cacheDirectory: true,
            },
          },
        ],
      },
      {
        test: /\.ya?ml$/,
        use: [
          'json-loader',
          'yaml-loader',
        ],
        exclude: /node_modules/
      },
      {
        test: /\.(css|styl)$/,
        loader: 'null-loader',
      },
      {
        test: /\.(png|jpg|gif|svg|woff2|eot|woff|ttf|ico)$/,
        loader: 'null-loader',
      },
      {
        test: /\.pug$/,
        loader: 'pug-plain-loader',
      },
    ],
  },
  mode: 'none',
  resolve,
};

module.exports = config;

执行的时候,直接用 shell 脚本来跑就行。

使用 Webpack + Mocha 进行单元测试(一)

我厂产品经过两年的打磨,目前功能基本稳定了,接下来的工作重点是用测试保证质量。除了继续丰富 E2E 测试,我还计划添加一些单元测试,用来确保一些重要函数和类正常工作。

所以就要选择框架。开始想试试近期比较热门的 Jest,找了些文章看了看,发现也没啥吸引我的特色,E2E 和 UI 我厂的 Navlang 目前独步江湖,无出其右者,考虑到以前用 Mocha 写过一些单元测试,所以决定继续用 Mocha。

但是已经很长时间没写了,所以想先研究下工具链。如果只是单文件的话,直接 mocha test.js 就好;如果测试文件用了 ESM,那么加上 @babel/register 也就够了,mocha —require @babel/register test.js

但是我们项目用到了 Vue,还用 Webpack 里的 resolve 定义了很多目录,所以为了能够兼容项目代码,我必须要 Mocha 结合 Webpack,用这个关键词一搜索,得到两个结论:mocha-webpack 和 mocha-loader。

前者已经一年多没更新了,而且要求 mocha@5,所以我就不想用了。转过头研究 mocha-loader,经过反复试验,加上阅读源码,我得出结论:

mocha-loader 的目标是在 Webpack 里继承测试,比如边开发边测试,并不是我想要的,打包测试内容,整合测试框架,方便用户在 CI 系统里集中进行测试。

所以我真正需要的,其实是:

  1. 创建一个独立的 webpack 配置文件,用来打包单元测试
  2. 打包后执行测试,返回测试结果

基本上,今天大半天的工作是白费了。mocha-loader 的作者应该把目的写在 README 里的……

GitChat: 使用 webpack 开发企业官网

最近我厂官网改版,我尝试用 Webpack 重建了开发工具链,效果不错,配置代码少了很多,逻辑更加简单清晰。我觉得值得拿出来分享一下。

最近我厂官网改版,我尝试用 Webpack 重建了开发工具链,效果不错,配置代码少了很多,逻辑更加简单清晰。我觉得值得拿出来分享一下。

文章已经发布,慢慢写了将近5w字,干货很多,覆盖面很广,欢迎大家前去阅读:升级工具链吧!使用 Webpack 开发企业官网。感谢大家的支持。

交流应该会通过直播进行,暂定7月中吧,斗鱼直播间:douyu.tv/meathill。

继续阅读“GitChat: 使用 webpack 开发企业官网”

最近折腾 @babel/preset-env 的一些小心得

近来厂里的项目越来越多,代码共享必不可少。我现在采取的方案是:

  1. 把公共组件拿出来,开一个新仓库
  2. 使用 webpack 进行打包编译,libraryTarget: 'umd'
  3. 将打包编译的代码一起提交到仓库
  4. 使用 npm i <owner>/<repo> -S 安装依赖,因为我厂的仓库均为私有,所以不能发布到 NPM

这套方案简单好用,实操效果良好。接下来我希望优化打包结果,于是研究了打包配置项,下面是我的一点心得。

继续阅读“最近折腾 @babel/preset-env 的一些小心得”

近期用 webpack-dev-server 作代理的一些经验

使用 webpack-dev-server 代理远程服务器;修改 http header 以便本地登录;代理 WebSocket。

如今前端开发使用 webpack-dev-server 作为本地服务器已经是基本配置,加上 proxy 功能可以很好的应对 SSL、跨域、线上环境切换等需求。Vue CLI 3 里也做了相应的集成,用起来很方便。

继续阅读“近期用 webpack-dev-server 作代理的一些经验”

Vue 小贴士

1. 使用 Vue + Webpack 开发
2. 使用 CDN 加载依赖
3. 在开发阶段尽量不要使用压缩的文件,一边取得尽量全面的错误信息

书说简短:

  1. 使用 Vue + Webpack 开发
  2. 使用 CDN 加载依赖
  3. 在开发阶段尽量不要使用压缩的文件,一边取得尽量全面的错误信息

继续阅读“Vue 小贴士”

Webpack 笔记

记录一些 webpack 的使用经验。我是渐进式使用 webpack 的,一开始只用它打包 js。但是现在开始会把越来越多的依赖交给它管理,所以记一篇笔记。这里不会教怎么使用,而是结合开发经验,总结一些特定需求的解决方案。

我使用的版本:3.5.1

我是渐进式使用 webpack 的,一开始只用它打包 js。但是现在开始会把越来越多的依赖交给它管理,所以记一篇笔记。这篇不是教程,而是结合开发经验,总结一些特定需求的解决方案。

继续阅读“Webpack 笔记”

使用 Webpack 时需避免循环引用

使用 Webpack 等打包工具时,需要注意尽量避免循环引用,即 A 引用 B,B 也引用 A,不然可能出现难以预料的问题。

开发日历控件的时候,对方变更了一下需求,基本上将最终产品分成两个:

  1. 选择连续时间段
  2. 选择多个不连续时间

那么我们知道,对于这种大部分功能一致,只有若干函数逻辑不同的产品,最合适的就是状态模式。于是很自然的,我就拿“2”作为标准模式,“1”作为新模式,将其重构成父类和子类,大概关系如下:

// 父类
// DatePicker.js

import RangeDatePicker from './RangeDatePicker';

class DatePicker {
  ....
  static getInstance(el, options) {
    if (options.scattered) {
      return new DatePicker(el, options);
    } else {
      return new RangeDatePicker(el, options);
    }
}


// 子类
// RangeDatePicker.js

import DatePicker from './DatePicker';

class RangeDatePicker extends DatePicker {

}

因为这个类只有两个成员,所以我把工厂方法 .getInstance() 放到了父类里面,通过判断参数确定应该返回哪一类实例。代码写完,测试的时候却报错:

Super expression must either be null or a function, not undefined

这个意思很明显,被继承的父类不能未定义。然则 DatePicker 明明是定义了的,只是验证两个类文件的话,均未出现任何语法错误。

遇事不决先 Google,还真找到很多结果,不过大多数都和 React.Component 有关,翻了半天一无所获,只好自力更生。打开 Chrome 开发者工具,勾上“Pause on Exceptions”,观察发生异常时的状况,一遍又一遍,我渐渐意识到,发生这个错误的时候,DatePicker 还未能在 webpack 的环境中完成注册。问题找到了!

与其它编译类语言不同,JS 是动态语言,所有 JS 代码都是放到统一的环境里跑的,类的代码如此,import 也是如此。所以对于其他语言,比如 ActionScript、Java,循环引用,即 A 引用 B,B 也引用 A,是没问题的,因为类的代码都会编译到执行文件,执行的时候,都已经在环境中;而 JS 是边执行边置入环境,具体到我这里,在将父类 DatePicker 放入环境时,会先 import 子类 RangeDatePicker 的代码,而子类又会要求 import 父类的代码,父类的代码正在引入中,于是便产生了问题。

想明白这点,后面就好办了,直接创建一个工厂类,把工厂方法放到里面执行,问题便解决了:

import DatePicker from './DatePicker';
import RangeDatePicker from './RangeDatePicker';

export default {
  createDatePicker(el, options) {
    if (options.scattered) {
      return new DatePicker(el, options);
    } else {
      return new RangeDatePicker(el, options);
    }
  }
}

PS:当年写依赖注入和包管理工具的时候,就卡在这个地方,怎么都想不通,于是一直也没写完。没想到这些个浓眉大眼有头发的,也都这么不负责任,这种问题都不解决就搞出来让全世界人用了。

Gulp 中顺序执行任务

Gulp 顺序执行支持3中模式:callback、返回 stream、返回 Promise 对象。

书接上文,Chrome 插件中无法直接使用 Handlebars 处理模板。两种方案,一是利用沙箱,将 .eval() 放在独立的环境中执行,好处是其它跨域的操作也能这样处理,坏处是写起来麻烦。另一种则是利用 Handlebars 的“预编译”功能,将模板提前编译好,直接在代码中引用。好处是写起来更顺畅,并且从发布插件的角度来看,早晚都要这样做。

我决定选用后者,于是我需要把模板提取出来进行预编译,然后我准备写个 Gulp 任务来搞定这个。

从页面中提取模板不算太难,写个正则就好,这里提前约定,模板使用 <script type="x-handlebars-template"> 标签包裹。

gulp.task('template', function () {
  let promise = new Promise((resolve, reject) => {
    fs.readFile('popup.html', (err, content) => {
      if (err) reject(err);
      resolve(content);
    }
  });
  promise.then((content) => {
    content.replace(/<script([^>]*)>([\S\s]+?)<\/script>/g, (match, attr, template) {
      // 具体处理模板,略掉了
    });
  })
});

模板编译之后,还需要用 Webpack 打包才能使用,于是要增加 Webpack 的任务。这个比较简单,参考它的 文档 即可。不过很明显,必须等全部模板预编译完成才能打包。之前我已经试过用 run sequence 顺序执行任务,不过这里我用到 Promise,情况似乎有变。

稍微 Google 一下,得知要能顺序执行任务有三种选择:

使用 callback

gulp.task('task', function (callback) {
  setTimeout(function () {
    // 任务执行完成后,调用 callback
    callback();
  }, 5000);
});

返回 stream

这个好像是标准做法,也是我之前做的。

gulp.task('task', function (callback) {
   returen gulp.src('*.js')
     .pipe(uglify())
     .pipe(gulp.desc('dist/');
});

返回 Promise 对象

gulp.task('task', function () {
  return new Promise(resolve, reject) => {
    resolve();
  });
});

既然支持 Promise 那就好办了,在 .then() 前面加一个 return 就好。


完整代码

参考文章

Handling Sync Tasks with Gulp JS