grunt 插件_从Grunt测试Grunt插件

最新推荐文章于 2020-09-23 18:10:22 发布

dnc8371

最新推荐文章于 2020-09-23 18:10:22 发布

阅读量195

点赞数

文章标签：单元测试 python javascript java vue ViewUI

原文链接：https://www.javacodegeeks.com/2015/02/testing-grunt-plugin-from-grunt.html

版权

grunt 插件

编写针对grunt插件的测试结果比预期的要简单。我需要运行多个任务配置，并想通过在主目录中键入grunt test来调用它们。

在第一个任务失败后，咕声通常会退出。这使得不可能在主项目gruntfile中存储多个失败方案。从那里运行它们将需要--force选项，但是grunt会忽略所有不是最佳的警告。

较干净的解决方案是在单独的目录中有一堆gruntfile，然后从主项目gruntfile调用它们。这篇文章解释了如何做到这一点。

示范项目

演示项目是带有一个grunt任务的小型grunt插件。根据action options属性的值，任务要么失败并显示警告，要么将成功消息打印到控制台中。

任务：

grunt.registerMultiTask('plugin_tester', 'Demo grunt task.', function() {
  //merge supplied options with default options
  var options = this.options({ action: 'pass', message: 'unknown error'});

  //pass or fail - depending on configured options
  if (options.action==='pass') {
    grunt.log.writeln('Plugin worked correctly passed.');
  } else {
    grunt.warn('Plugin failed: ' + options.message);
  }
});

有三种不同的方式编写grunt插件单元测试。每个解决方案在test目录中都有自己的nodeunit文件，并在这篇文章中进行说明：

plugin_exec_test.js –最实用的解决方案，
plugin_fork_test.js – 解决了先前解决方案失败的罕见情况，
plugin_spawn_test.js – 可能，但最不实用。

所有这三个演示测试都包含三种不同的任务配置：

// Success scenario
options: { action: 'pass' }
// Fail with "complete failure" message
options: { action: 'fail', message: 'complete failure' }
//Fail with "partial failure" message
options: { action: 'fail', message: 'partial failure' }

每个配置都存储在test目录内的单独gruntfile中。例如，存储在gruntfile-pass.js文件中的成功方案如下所示：

grunt.initConfig({
  // prove that npm plugin works too
  jshint: { 
    all: [ 'gruntfile-pass.js' ] 
  },
  // Configuration to be run (and then tested).
  plugin_tester: { 
    pass: { options: { action: 'pass' } } 
  }
});

// Load this plugin's task(s).
grunt.loadTasks('./../tasks');
// next line does not work - grunt requires locally installed plugins
grunt.loadNpmTasks('grunt-contrib-jshint');

grunt.registerTask('default', ['plugin_tester', 'jshint']);

这三个测试gruntfiles看起来几乎相同，只有plugin_tester目标的options对象改变了。

从子目录运行Gruntfile

我们的测试gruntfiles存储在test子目录中，而grunt不能很好地处理这种情况。本章介绍了问题所在，并介绍了两种解决方法。

问题

要查看问题，请转到演示项目目录并运行以下命令：

grunt --gruntfile test/gruntfile-problem.js

Grunt响应以下错误：

Local Npm module "grunt-contrib-jshint" not found. Is it installed?
Warning: Task "jshint" not found. Use --force to continue.

Aborted due to warnings.

说明

Grunt假定grunfile和node_modules存储库存储在同一目录中。虽然node.js require函数会在所有父目录中搜索所需模块，但loadNpmTasks不会。

这个问题有两种可能的解决方案，一种简单而有趣：

在测试目录（简单）中创建本地npm存储库，
从父目录中执行繁重的加载任务（ fancy ）。

尽管第一个“简单”解决方案比较干净，但演示项目使用了第二个“精美”解决方案。

解决方案1：复制Npm存储库

主要思想很简单，只需在tests目录内创建另一个本地npm存储库：

将package.json文件复制到tests目录。
向其中添加仅测试依赖项。
每次运行测试时，请运行npm install命令。

这是更清洁的解决方案。它只有两个缺点：

测试依赖项必须单独维护，
所有插件依赖项都必须安装在两个位置。

解决方案2：从父目录加载Grunt任务

另一个解决方案是强制grunt从存储在另一个目录中的npm存储库加载任务。

Grunt插件加载

Grunt有两种方法可以加载插件：

loadTasks('directory-name') –将所有任务加载到目录中，
loadNpmTasks('plugin-name') –加载插件定义的所有任务。

loadNpmTasks函数采用grunt插件和模块存储库的固定目录结构。它猜测应该存储任务的目录名称，然后调用loadTasks('directory-name')函数。

本地npm存储库为每个npm软件包都有单独的子目录。所有grunt插件都应该具有tasks子目录，并且其中的.js文件都包含任务。例如， loadNpmTasks('grunt-contrib-jshint')调用从node_mudules/grunt-contrib-jshint/tasks目录加载任务，等效于：

grunt.loadTasks('node_modules/grunt-contrib-jshint/tasks')

因此，如果要从父目录加载grunt-contrib-jshint插件的所有任务，可以执行以下操作：

grunt.loadTasks('../node_modules/grunt-contrib-jshint/tasks')

循环父目录

更为灵活的解决方案是遍历所有父目录，直到找到最近的node_modules存储库或到达根目录为止。这是在grunt-hacks.js模块内部实现的。

loadParentNpmTasks函数循环父目录：

module.exports = new function() {

  this.loadParentNpmTasks = function(grunt, pluginName) {
    var oldDirectory='', climb='', directory, content;

    // search for the right directory
    directory = climb+'node_modules/'+ pluginName;
    while (continueClimbing(grunt, oldDirectory, directory)) {
      climb += '../';
      oldDirectory = directory;
      directory = climb+'node_modules/'+ pluginName;
    }

    // load tasks or return an error
    if (grunt.file.exists(directory)) {
      grunt.loadTasks(directory+'/tasks');
    } else {
      grunt.fail.warn('Tasks plugin ' + pluginName + ' was not found.');
    }
  }

  function continueClimbing(grunt, oldDirectory, directory) {
    return !grunt.file.exists(directory) &&
      !grunt.file.arePathsEquivalent(oldDirectory, directory);
  }

}();

修改后的Gruntfile

最后，我们需要通过以下步骤替换grunt.loadNpmTasks('grunt-contrib-jshint')中通常的grunt.loadNpmTasks('grunt-contrib-jshint')调用：

var loader = require("./grunt-hacks.js");
loader.loadParentNpmTasks(grunt, 'grunt-contrib-jshint');

缩短的gruntfile：

module.exports = function(grunt) {
  var loader = require("./grunt-hacks.js");

  grunt.initConfig({
    jshint: { /* ... */  },
    plugin_tester: { /* ... */ }
  });

  grunt.loadTasks('./../tasks');
  loader.loadParentNpmTasks(grunt, 'grunt-contrib-jshint');
};

缺点

该解决方案有两个缺点：

它不处理集合插件。
如果grunt曾经改变grunt插件的预期结构，则必须修改解决方案。

如果您还需要集合插件，请查看grunts task.js以了解如何支持它们。

从Java脚本调用Gruntfile

我们需要做的第二件事是从javascript调用gruntfile。唯一的麻烦是，咕unt声会在任务失败时退出整个过程。因此，我们需要从子进程中调用它。

节点模块子进程具有三种不同的功能，能够在子进程内部运行命令：

exec –在命令行执行命令，
spawn –在命令行上执行命令的方式不同，
fork –在子进程中运行节点模块。

第一个是exec ，最易于使用，并在第一章中进行了说明。第二章介绍了如何使用fork以及为什么它不如exec最佳。第三章是关于生成。

执行力

Exec在子进程中运行命令行命令。您可以指定要在哪个目录中运行它，设置环境变量，设置超时，然后在该超时后将命令终止。当命令完成运行时，exec调用回调并将其传递给stdout流，stderr流和命令崩溃时的错误。

除非另有配置，否则命令将在当前目录中运行。我们希望它在tests子目录中运行，所以我们必须指定options对象的cwd属性： {cwd: 'tests/'} 。

stdout和stderr流内容都存储在缓冲区中。每个缓冲区的最大大小设置为204800，如果命令产生更多输出，则exec调用将崩溃。这笔钱足以应付我们的小任务。如果需要更多，则必须设置maxBuffer options属性。

致电执行

以下代码段显示了如何从exec运行gruntfile。该函数是异步的，并在完成之后调用whenDoneCallback ：

var cp = require("child_process");

function callGruntfile(filename, whenDoneCallback) {
  var command, options;
  command = "grunt --gruntfile "+filename+" --no-color";
  options = {cwd: 'test/'};
  cp.exec(command, options, whenDoneCallback);
}

注意：如果将npm安装到测试目录（简单解决方案），则需要使用callNpmInstallAndGruntfile函数而不是callGruntfile ：

function callNpmInstallAndGruntfile(filename, whenDoneCallback) {
  var command, options;
  command = "npm install";
  options = {cwd: 'test/'};
  cp.exec(command, {}, function(error, stdout, stderr) {
    callGruntfile(filename, whenDoneCallback);
  });
}

单元测试

第一节点单元测试运行成功方案，然后检查流程是否成功完成而没有失败，标准输出是否包含预期的消息以及标准错误是否为空。

成功场景单元测试：

pass: function(test) {
  test.expect(3);
  callGruntfile('gruntfile-pass.js', function (error, stdout, stderr) {
    test.equal(error, null, "Command should not fail.");
    test.equal(stderr, '', "Standard error stream should be empty.");

    var stdoutOk = contains(stdout, 'Plugin worked correctly.');
    test.ok(stdoutOk, "Missing stdout message.");
    test.done();
  });
},

第二节点单元测试运行“完全失败”方案，然后检查进程是否按预期失败。请注意，标准错误流为空，警告被打印到标准输出中。

失败的场景单元测试：

fail_1: function(test) {
  test.expect(3);
  var gFile = 'gruntfile-fail-complete.js';
  callGruntfile(gFile, function (error, stdout, stderr) {
    test.equal(error, null, "Command should have failed.");
    test.equal(error.message, 'Command failed: ', "Wrong error message.");
    test.equal(stderr, '', "Non empty stderr.");

    var stdoutOk = containsWarning(stdout, 'complete failure');
    test.ok(stdoutOk, "Missing stdout message.");
    test.done();
  });
}

第三次“部分故障”节点单元测试与之前的测试几乎相同。整个测试文件可在github上找到。

缺点

坏处：

必须预先设置最大缓冲区大小。

叉子

Fork在子进程中运行node.js模块，等效于在命令行上调用node <module-name> 。 Fork使用回调将标准输出和标准错误发送给调用方。两个回调都可以被多次调用，并且调用方可以分段获取子进程的输出。

仅在需要处理任意大小的stdout和stderr或需要自定义grunt功能时，使用fork才有意义。如果您不这样做，则exec更易于使用。

本章分为四个子章节：

从javascript 呼叫grunt ，
读取节点模块中的命令行参数，
在子进程中启动节点模块，
编写单元测试。

呼唤咕unt声

Grunt并非以编程方式被调用。它没有公开“公共” API，也没有对其进行记录。

我们的解决方案模仿了grunt-cli的功能，因此相对安全。 Grunt-cli与grunt核心分开分发，因此更改的可能性较小。但是，如果确实更改，则此解决方案也必须更改。

从javascript运行咕unt声需要我们执行以下操作：

将gruntfile名称与其路径分开，
更改活动目录，
调用grunts tasks功能。

从javascript呼叫grunt：

this.runGruntfile = function(filename) {
  var grunt = require('grunt'), path = require('path'), directory, filename;
  
  // split filename into directory and file
  directory = path.dirname(filename);
  filename = path.basename(filename);

  //change directory
  process.chdir(directory);

  //call grunt
  grunt.tasks(['default'], {gruntfile:filename, color:false}, function() {
    console.log('done');
  });
};

模块参数

该模块将从命令行调用。节点将命令行参数保留在内部
process.argv数组：

module.exports = new function() {
  var filename, directory;

  this.runGruntfile = function(filename) {
    /* ... */
  };

  //get first command line argument
  filename = process.argv[2];
  this.runGruntfile(filename);
}();

呼叫叉

Fork具有三个参数：模块的路径，带有命令行参数的数组和options对象。使用tests/Gruntfile-1.js参数调用module.js ：

child = cp.fork('./module.js', ['tests/Gruntfile-1.js'], {silent: true})

silent: true选项使返回的child进程的stdout和stderr在父级内部可用。如果将其设置为true，则返回的对象将提供对调用者的stdout和stderr流的访问。

在每个流上调用on('data', callback) 。每次子进程向流发送某些内容时，都会调用传递的回调：

child.stdout.on('data', function (data) {
  console.log('stdout: ' + data); // handle piece of stdout
});
child.stderr.on('data', function (data) {
  console.log('stderr: ' + data); // handle piece of stderr
});

子进程可能崩溃或正常结束其工作：

child.on('error', function(error){
  // handle child crash
  console.log('error: ' + error); 
});
child.on('exit', function (code, signal) {
  // this is called after child process ended
  console.log('child process exited with code ' + code); 
});

演示项目使用以下函数来调用fork和绑定回调：

/**
 * callbacks: onProcessError(error), onProcessExit(code, signal), onStdout(data), onStderr(data)
 */
function callGruntfile(filename, callbacks) {
  var comArg, options, child;
  callbacks = callbacks || {};

  child = cp.fork('./test/call-grunt.js', [filename], {silent: true});

  if (callbacks.onProcessError) {
    child.on("error", callbacks.onProcessError);
  }
  if (callbacks.onProcessExit) {
    child.on("exit", callbacks.onProcessExit);
  }
  if (callbacks.onStdout) {
    child.stdout.on('data', callbacks.onStdout);
  }
  if (callbacks.onStderr) {
    child.stderr.on('data', callbacks.onStderr);
  }
}

编写测试

每个单元测试都调用callGruntfile函数。回调会在标准输出流中搜索所需的内容，检查退出代码是否正确，在错误流中出现错误时失败，或者在fork调用返回错误时失败。

成功场景单元测试：

pass: function(test) {
  var wasPassMessage = false, callbacks;
  test.expect(2);
  callbacks = {
    onProcessError: function(error) {
      test.ok(false, "Unexpected error: " + error);
      test.done();
    },
    onProcessExit: function(code, signal) {
      test.equal(code, 0, "Exit code should have been 0");
      test.ok(wasPassMessage, "Pass message was never sent ");
      test.done();
    },
    onStdout: function(data) {
      if (contains(data, 'Plugin worked correctly.')) {
        wasPassMessage = true;
      }
    },
    onStderr: function(data) {
      test.ok(false, "Stderr should have been empty: " + data);
    }
  };
  callGruntfile('test/gruntfile-pass.js', callbacks);
}

对应于失败场景的测试几乎相同，可以在github上找到。

缺点

缺点：

使用的grunt函数不属于官方API。
子进程输出流以块而不是一个大块的形式提供。

产生

Spawn是fork和exec之间的交叉。与exec类似，spawn能够运行可执行文件并向其传递命令行参数。子进程输出流的处理方式与fork中的处理方式相同。它们通过回调分段发送给父级。因此，与使用fork一样，仅当需要任意大小的stdout或stderr时，使用spawn才有意义。

问题

产卵的主要问题发生在Windows上。必须准确指定要运行的命令的名称。如果使用参数grunt调用spawn，则spawn期望可执行文件名不带后缀。 grunt.cmd真正的grunt可执行文件grunt.cmd 。否则， spawn 忽略Windows环境变量PATHEXT 。

循环后缀

如果要从spawn调用grunt ，则需要执行以下操作之一：

针对Windows和Linux使用不同的代码，或者
从环境中读取PATHEXT并循环遍历，直到找到正确的后缀。

以下函数循环遍历PATHEXT并将正确的文件名传递给回调：

function findGruntFilename(callback) {
  var command = "grunt", options, extensionsStr, extensions, i, child, onErrorFnc, hasRightExtension = false;

  onErrorFnc = function(data) {
    if (data.message!=="spawn ENOENT"){
      grunt.warn("Unexpected error on spawn " +extensions[i]+ " error: " + data);
    }
  };

  function tryExtension(extension) {
    var child = cp.spawn(command + extension, ['--version']);
    child.on("error", onErrorFnc);
    child.on("exit", function(code, signal) {
      hasRightExtension = true;
      callback(command + extension);
    });
  }

  extensionsStr = process.env.PATHEXT || '';
  extensions = [''].concat(extensionsStr.split(';'));
  for (i=0; !hasRightExtension && i<extensions.length;i++) {
    tryExtension(extensions[i]);
  }
}

编写测试

一旦有了grunt命令名，就可以调用spawn 。 Spawn会触发与fork完全相同的事件，因此
callGruntfile接受完全相同的回调对象，并将其属性绑定到子进程事件：

function callGruntfile(command, filename, callbacks) {
  var comArg, options, child;
  callbacks = callbacks || {};

  comArg = ["--gruntfile", filename, "--no-color"];
  options = {cwd: 'test/'};
  child = cp.spawn(command, comArg, options);
  
  if (callbacks.onProcessError) {
    child.on("error", callbacks.onProcessError);
  }
  /* ... callbacks binding exactly as in fork ...*/
}

测试也几乎与上一章中的测试相同。唯一的区别是，在执行其他所有操作之前，您必须先找到grunt可执行文件名。成功场景测试如下所示：

pass: function(test) {
  var wasPassMessage = false;
  test.expect(2);
  findGruntFilename(function(gruntCommand){
    var callbacks = {
      /* ... callbacks look exactly the same way as in fork ... */
    };
    callGruntfile(gruntCommand, 'gruntfile-pass.js', callbacks);
  });
}

完整的成功方案测试以及两个失败方案测试都可以在github上获得。

缺点

缺点：

Spawn会忽略PATHEXT后缀，需要使用自定义代码来处理它。
子进程输出流以块而不是一个大块的形式提供。

结论

有三种方法可以从gruntfile内部测试grunt插件。除非您有非常强烈的理由不这样做，否则请使用exec 。

翻译自: https://www.javacodegeeks.com/2015/02/testing-grunt-plugin-from-grunt.html

grunt 插件

dnc8371

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
grunt 插件_从Grunt测试Grunt插件

grunt 插件编写针对grunt插件的测试结果比预期的要简单。我需要运行多个任务配置，并想通过在主目录中键入grunt test来调用它们。在第一个任务失败后，咕声通常会退出。这使得不可能在主项目gruntfile中存储多个失败方案。从那里运行它们将需要--force选项，但是grunt会忽略所有不是最佳的警告。较干净的解决方案是在单独的目录中有一堆gruntfile，然...
复制链接

扫一扫